[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Changes to Audio Sink / Source ?
From: |
Michael Dickens |
Subject: |
[Discuss-gnuradio] Changes to Audio Sink / Source ? |
Date: |
Wed, 30 Nov 2005 12:32:13 -0500 |
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.
- [Discuss-gnuradio] Changes to Audio Sink / Source ?,
Michael Dickens <=