[alsa-devel] driver silence callback
Greetings,
Is the driver's silence callback meant to be able to *overwrite* some part of the audio buffer that has already been written e.g. via the playback *copy* callback?
In the case of my (older) hardware, once audio has been written via the copy callback, it is gone (into a fifo), there is no way to overwrite with silence.
The asihpi silence call back will _append_ a period of silence to the already written audio queue. I'm wondering if this is wrong?
Perhaps I should not have a silence callback at all?
I'm looking at the case in pcm_lib.c snd_pcm_playback_silence() where "when runtime->silence_size >= runtime->boundary - fill processed area with silence immediately"
My reference for silence callback. http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch11s02.html
regards
Eliot
Eliot Blennerhassett wrote:
Is the driver's silence callback meant to be able to *overwrite* some part of the audio buffer that has already been written e.g. via the playback *copy* callback?
No.
I'm looking at the case in pcm_lib.c snd_pcm_playback_silence() where "when runtime->silence_size >= runtime->boundary - fill processed area with silence immediately"
When underrun detection is disabled, this mechanism can be used to fill some part of the buffer with silence immediately after the hardware has read from this part of the buffer, so that in case of an underrung, not the old data but silence is played.
In other words, the silence callbacks initializes the buffer, while the copy callback later fills the same part of the buffer with actual data.
In the case of my (older) hardware, once audio has been written via the copy callback, it is gone (into a fifo), there is no way to overwrite with silence.
Ensure that on a FIFO underrun, silence is played. This might be the default on your hardware anyway. :)
Regards, Clemens
Thanks Clemens,
On 24/03/11 20:21, Clemens Ladisch wrote:
When underrun detection is disabled, this mechanism can be used to fill some part of the buffer with silence immediately after the hardware has read from this part of the buffer, so that in case of an underrun, not the old data but silence is played.
In other words, the silence callbacks initializes the buffer, while the copy callback later fills the same part of the buffer with actual data.
Aha. My silence callback was sending silence to the fifo, then the copy callback can do nothing but append audio *after* the silence. No wonder the audio was choppy!
In the case of my (older) hardware, once audio has been written via the copy callback, it is gone (into a fifo), there is no way to overwrite with silence.
Ensure that on a FIFO underrun, silence is played. This might be the default on your hardware anyway. :)
Yes, our hardware can't operate otherwise. If I write 1000 frames to the stream, it will play those and then stop. i.e. output silence.
I think I still need a silence callback that does nothing, otherwise I can't use the copy callback. (snd_pcm_lib_writev_transfer will fail and call snd_BUG_ON)
-- Eliot
participants (2)
-
Clemens Ladisch -
Eliot Blennerhassett