Re: [pulseaudio-discuss] Documentation for how rewinding works

Re: [pulseaudio-discuss] Documentation for how rewinding works

[Raymond Yau]

2012-8-19 下午7:17 於 "Tanu Kaskinen" <tanuk@iki.fi> 寫道：
>
> Hi,
>
> While reviewing a rewind related patch, I noticed that I don't
> understand the rewinding code thoroughly, even though I have studied it
> a few times in the past. I decided that I should write a wiki page for
> the code so that working with it would be easier in the future for me
> and everybody else.
>
> So, here's the result:
>
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding
>
> While doing that, I found quite a few bugs, which are noted on that
> page. I don't plan fixing them any time soon (help with that would be
> very welcome), so I will just file bugs about the issues so that they
> are not forgotten.
>
it seem that the alsa sink is more complicated than your figure.

Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy
Efficient HA audio mechanism

most sound cards have fixed size FIFO buffer instead of dynamic FIFO and
minimum transfer size(brust) similar to hda controller which snd_pcm_rewind
cannot rewind any audio data in those first in first out buffer.

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8

1) do the server really need to rewind when there is only one pulse client ?

2) does pulseaudio add this rewind safeguard delay to the latency ?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [pulseaudio-discuss] Documentation for how rewinding works

[Tanu Kaskinen]

On Wed, 2012-08-22 at 09:14 +0800, Raymond Yau wrote:
> 2012-8-19 下午7:17 於 "Tanu Kaskinen" <tanuk@iki.fi> 寫道：
> >
> > Hi,
> >
> > While reviewing a rewind related patch, I noticed that I don't
> > understand the rewinding code thoroughly, even though I have studied it
> > a few times in the past. I decided that I should write a wiki page for
> > the code so that working with it would be easier in the future for me
> > and everybody else.
> >
> > So, here's the result:
> >
> http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding
> >
> > While doing that, I found quite a few bugs, which are noted on that
> > page. I don't plan fixing them any time soon (help with that would be
> > very welcome), so I will just file bugs about the issues so that they
> > are not forgotten.
> >
> it seem that the alsa sink is more complicated than your figure.

The fact that there's a region in the beginning of the sink buffer that
shouldn't be rewound is an implementation detail of alsa sink, and does
not need to be taken into account in the general rewind handling. The
alsa sink is able to take care of it internally.

> Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy
> Efficient HA audio mechanism
> 
> most sound cards have fixed size FIFO buffer instead of dynamic FIFO and
> minimum transfer size(brust) similar to hda controller which snd_pcm_rewind
> cannot rewind any audio data in those first in first out buffer.
> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8

Thanks for bringing that commit into attention, because it seems to
introduce a new bug (although judging from the commit message, Pierre
was aware of it and considered it a feature): the code doesn't take
tsched_watermark into account anymore when doing rewinds. The point of
tsched_watermark is to ensure that pulseaudio has enough time to fill
the sink buffer. If it's ignored when rewinding, it's likely that there
will be an underrun when refilling the sink buffer, if tsched_watermark
is greater than rewind_safeguard.

> 1) do the server really need to rewind when there is only one pulse client ?

Yes. The sink buffer may have up to 2 seconds of audio from the one
pulse client, and if you then change the software volume of the sink (or
sink input, doesn't matter), you will have to rewrite the sink buffer
contents unless you want to wait 2 seconds until the volume change
becomes audible.

> 2) does pulseaudio add this rewind safeguard delay to the latency ?

Unless I'm misunderstanding what you mean by "the latency", the rewind
safeguard doesn't add any latency, so there's nothing to worry about.

-- 
Tanu

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [pulseaudio-discuss] Documentation for how rewinding works

[Raymond Yau]

> > >
> > it seem that the alsa sink is more complicated than your figure.
>
> The fact that there's a region in the beginning of the sink buffer that
> shouldn't be rewound is an implementation detail of alsa sink, and does
> not need to be taken into account in the general rewind handling. The
> alsa sink is able to take care of it internally.
>
> > Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy
> > Efficient HA audio mechanism
> >
> > most sound cards have fixed size FIFO buffer instead of dynamic FIFO and
> > minimum transfer size(brust) similar to hda controller which
snd_pcm_rewind
> > cannot rewind any audio data in those first in first out buffer.
> >
> >
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8
>
> Thanks for bringing that commit into attention, because it seems to
> introduce a new bug (although judging from the commit message, Pierre
> was aware of it and considered it a feature): the code doesn't take
> tsched_watermark into account anymore when doing rewinds. The point of
> tsched_watermark is to ensure that pulseaudio has enough time to fill
> the sink buffer. If it's ignored when rewinding, it's likely that there
> will be an underrun when refilling the sink buffer, if tsched_watermark
> is greater than rewind_safeguard.

how about those sound cards which minimum latency is much higher than that
of pulse plugin

http://thread.gmane.org/gmane.linux.alsa.devel/89157/focus=89167

snd-ymfpci update the hwptr at 5.33 ms interval while pulse plugin claim to
support as low as 1ms

does the driver need to add another constraints which restrict the period
bytes to be multiple of 1024 at 48000Hz in addition to forcing the driver
to run at 48000Hz since hwptr only change at period boundary ?

with minimum period of 3 , the minimum buffer time of snd-ymfpci is 16ms

can pa server reject the pulse client when it request latency lower than
16ms (minimum period * minimum period time of the sound driver)?

>
> > 1) do the server really need to rewind when there is only one pulse
client ?
>
> Yes. The sink buffer may have up to 2 seconds of audio from the one
> pulse client, and if you then change the software volume of the sink (or
> sink input, doesn't matter), you will have to rewrite the sink buffer
> contents unless you want to wait 2 seconds until the volume change
> becomes audible.

when module-suspend-on-idle is loaded pa server close the sink after 5
seconds of no activity for power saving  and reopen the sink when another
appllication connect to play audio,  does it mean that rewind is not
necessary in this situation ?

Re: [pulseaudio-discuss] Documentation for how rewinding works

[Tanu Kaskinen]

On Mon, 2012-08-27 at 09:41 +0800, Raymond Yau wrote:
> 
> > > >
> > > it seem that the alsa sink is more complicated than your figure.
> >
> > The fact that there's a region in the beginning of the sink buffer
> that
> > shouldn't be rewound is an implementation detail of alsa sink, and
> does
> > not need to be taken into account in the general rewind handling.
> The
> > alsa sink is able to take care of it internally.
> >
> > > Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy
> > > Efficient HA audio mechanism
> > >
> > > most sound cards have fixed size FIFO buffer instead of dynamic
> FIFO and
> > > minimum transfer size(brust) similar to hda controller which
> snd_pcm_rewind
> > > cannot rewind any audio data in those first in first out buffer.
> > >
> > >
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8
> >
> > Thanks for bringing that commit into attention, because it seems to
> > introduce a new bug (although judging from the commit message,
> Pierre
> > was aware of it and considered it a feature): the code doesn't take
> > tsched_watermark into account anymore when doing rewinds. The point
> of
> > tsched_watermark is to ensure that pulseaudio has enough time to
> fill
> > the sink buffer. If it's ignored when rewinding, it's likely that
> there
> > will be an underrun when refilling the sink buffer, if
> tsched_watermark
> > is greater than rewind_safeguard.
> 
> how about those sound cards which minimum latency is much higher than
> that of pulse plugin
> 
> http://thread.gmane.org/gmane.linux.alsa.devel/89157/focus=89167
> 
> snd-ymfpci update the hwptr at 5.33 ms interval while pulse plugin
> claim to support as low as 1ms
> 
> does the driver need to add another constraints which restrict the
> period bytes to be multiple of 1024 at 48000Hz in addition to forcing
> the driver to run at 48000Hz since hwptr only change at period
> boundary ?

The period size doesn't affect much anything when pulseaudio is using
timer based scheduling. If the period size has implications on how much
it's safe to rewind, then that information would be nice to have, but I
don't know if there's any such connection.

> with minimum period of 3 , the minimum buffer time of snd-ymfpci is
> 16ms
> 
> can pa server reject the pulse client when it request latency lower
> than 16ms (minimum period * minimum period time of the sound driver)?

I'm not familiar with how the minimum latency affects alsa clients. I
think there has been complaints that things aren't currently handled
very well if the minimum latency conflicts with what an alsa application
has requested, so maybe I'll have a look at this at some point.

> >
> > > 1) do the server really need to rewind when there is only one
> pulse client ?
> >
> > Yes. The sink buffer may have up to 2 seconds of audio from the one
> > pulse client, and if you then change the software volume of the sink
> (or
> > sink input, doesn't matter), you will have to rewrite the sink
> buffer
> > contents unless you want to wait 2 seconds until the volume change
> > becomes audible.
> 
> when module-suspend-on-idle is loaded pa server close the sink after 5
> seconds of no activity for power saving  and reopen the sink when
> another appllication connect to play audio,  does it mean that rewind
> is not necessary in this situation ?

What rewind are you talking about here? Rewinds related to volume
changes are always necessary. But maybe you're talking about some
rewinds that happen when a new stream is created? If the sink was not
suspended when a new stream is connected to it, a rewind is definitely
needed. But if the sink was suspended, then it's less clear.

If the stream is immediately able to provide data to the sink, then
there's no need for a rewind (there's nothing to rewind anyway). But the
usual case is that the stream doesn't have any data available at the
moment when it's created (all native protocol streams fall into this
category, except maybe streams that start in the corked state...). In
this case the sink gets woken up from suspend, and since there's no data
available, it will fill its buffer with silence. When the stream gets
data from somewhere (a client, usually), then a rewind is made so that
the received audio doesn't have to wait for the silence to be played
first.

-- 
Tanu