[Discuss-gnuradio] Changes to Audio Sink / Source ?

[Michael Dickens]

I have an gr-audio-osx sink which works in the basic sense of working  
- no frills -, let's call it v0.1 since there are still some changes  
I need to make before it works well enough to be released into the  
wild.  In doing so, I've come up with some possible changes to the  
audio sink & sink API ... thought I'd throw them out & see what  
others think. - MLD

A) the API for "new" (e.g. audio_alsa_sink::audio_alsa_sink, audio- 
osx-sink::audio-osx-sink) varies from type to type.  For OSS and (at  
least for now) OSX, the parameters are:
 * int sampling_freq
 * const std::string dev

While for ALSA they are:
 * int sampling_freq
 * const std::string device_name
 * double period_time
 * int nperiods

Given that the audio source is determined "on the fly" by audio.py,  
in the order {ALSA, OSS, OSX, WINDOWS}, there is no real way to  
"know" that your program will be using one API or another.  Hence the  
audio API needs to be fixed for all audio output types.  Here is what  
I would propose:

 * int sampling_freq
 * const std::string device_name
 * double period_time
 * int nperiods
 * int &channel_config
 * int n_buffers

The extra inputs would be set to 0 by default, so as to provide  
backwards compatibility for current programs.

The first 2 are the same; the next 2 are same as for ALSA; the last 2  
are:
1* int &channel_config     .... or something similar which describes  
the type of audio output such as an enum including "mono", "stereo",  
"5 channel stereo", "5.1 surround", or whatever.  Leaves options for  
future expansion, and also allows the configuration to setup  
appropriate buffers for exactly the number of channels (as opposed to  
worst case).  The "&" is so that the audio_sink can change the value  
to whatever it can support, and report that back to the calling  
program (to check, presumedly).

2* int n_buffers     .... the number of buffer slots in the list  
("ring") before overrun occurs.  Not sure if this is really needed,  
as there is probably a way to determine this number dynamically.  But  
I think it would be nice for users to override that computation.

B) in "work" (e.g. audio-osx-sink::work ) for both source and sink,  
right now the input parameters are:
 * int noutput_items
 * gr_vector_const_void_star &input_items,
 * gr_vector_void_star &output_items

I would propose to add another parameter:
 * bool do_block     ... which would tell "work" to block (TRUE) or  
not (FALSE) until enough data is available to fill the buffer(s) (for  
source) or to play synchronously (for sink).  This parameter may be  
ignored by some OS's (e.g. OSX would ignore for the sink, because it  
turns out to always play asynchronously with respect to how GnuRadio  
operates).

So, yes, Eric, IMHO the audio API would benefit from allowing it to  
block or not depending on who wants to control data flow.  All of  
these could be added with default values, for backward compatibility  
for current programs ... but allowing future programs the benefit of  
the new options.