driver silence callback

driver silence callback

[Eliot Blennerhassett]

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

Re: driver silence callback

[Clemens Ladisch]

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

Re: driver silence callback

[Eliot Blennerhassett]

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