On Wed, May 13, 2009 at 12:09 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
>
> At Wed, 13 May 2009 09:38:50 -0400,
> Jon Smirl wrote:
> >
> > On Wed, May 13, 2009 at 9:25 AM, Jaroslav Kysela <perex@xxxxxxxx> wrote:
> > > On Wed, 13 May 2009, Jon Smirl wrote:
> > >
> > >> There's a long thread over on the pulse list about glitch free
> > >> playback. The glitches they are encountering are caused by CPU
> > >> scheduling latency. They are trying to fix this by setting HZ up to
> > >> 1000 and constantly polling the audio DMA queue to keep it 99% full.
> > >>
> > >> This doesn't seem like the right solution to me. It is fixing the
> > >> symptom not the cause. The cause is 200-300ms scheduling latency. The
> > >> source of that needs to be tracked down and fixed in the kernel. But
> > >> we have to live with the latencies until they are fixed.
> > >>
> > >> The strategy of checking the queue at 1000Hz works but it is very
> > >> inefficient. The underlying problem is that the buffer ALSA is using
> > >> is too small on systems with 300ms latency. The buffer is just big
> > >> enough to cover 300ms so they rapidly check and fill it at 1000Hz to
> > >> ensure that it is full if the 300ms latency strikes.
> > >
> > > ??? The ring buffer size is not limited if hw allows that.
> > >
> > >> On my hardware with period interrupts ALSA is only checking the buffer
> > >> at 8Hz. Since I'm checking appl_ptr I know when DMA over runs the
> > >> buffers. This allows me to insert silence and I could indicated this
> > >
> > > Inserting silence might be wrong, if you broke stream timing. The elapsed()
> > > callback should be called at exact timing (and position should be updated,
> > > too).
> > >
> > >> condition to ALSA if there was a mechanism for doing so. ALSA could
> > >> use this over run knowledge to measure scheduling latency and adjust
> > >> the buffering.
> > >>
> > >> But the DMA interface between ALSA and the driver has been fixed at
> > >> stream creation time. There's no way to dynamically alter it (like
> > >> window size changes in TCP/IP). With networking you get a list of
> > >> buffers to send. As you send these buffers you mark them sent. The
> > >> core is free to hand you buffers straight from user space or do copies
> > >> and use internal ring buffers. The network driver just gets a list of
> > >> physical addresses to send. This buffer bookkeeping could occur in
> > >> snd_pcm_period_elapsed().
> > >>
> > >> A dynamic chaining mechanism allows you to alter the buffering
> > >> mid-stream. If the driver indication a DMA over run error this tells
> > >> ALSA that it needs to insert another buffer. After a while these
> > >> errors will stop and ALSA will have measured worst case CPU scheduling
> > >> latency. From then on it will know the exact size of buffering needed
> > >> for the kernel it it running on and it can use this knowledge at
> > >> stream creation time. Now filling the buffer at 8Hz or lower will work
> > >> and you don't have to spend the power associated with 1000Hz timer
> > >> interrupts.
> > >
> > > Nothing prevents to application to allocate a big ring buffer and write
> > > samples only as necessary. Application is a producer and controller in this
> > > case. The midlevel layer can hardly do something if samples are not
> > > available. The situation will be more or less bad.
> >
> > Who is going to dynamically measure the scheduling latency of the
> > kernel and compute the correct buffer size for the low level driver?
> > You can't expect every app to do that.
> >
> > > The whole problem is that standard Linux kernel is not realtime, but audio
> > > is realtime task.
> >
> > By that definition networking is a real time task too, but it's not.
> >
> > Playing MP3s is not a real-time task. The buffering system between the
> > app and ALSA's DMA system is not properly communicating feedback and
> > that's what is causing the problem. Networking has a correct feedback
> > look and doesn't get into trouble. ALSA's buffering system isn't
> > flexible enough to hide these big scheduling latencies without losing
> > data.
>
> It's not about flexibility. The current audio system itself is
> flexible enough to solve the problem you mentioned. But you just need
> to do everything by yourself. A car with manual gears is as flexible
> as a car with automatic gears from the performance POV, but a driver
> needs more work to run it smoothly.
>
> Also, the automation isn't the best thing. For example, think about
> automatic resizing the buffer and restarting the stream: do you really
> want this for the system like JACK? No...
>
> However, obviously, there is a big missing piece here - some
> automation for an easy stream handling, including the automatic buffer
> optimization for lazy jobs like MP3 player. IMO, this isn't
> necessarily in the kernel driver at all. It's rather far better
> implemented in the user space.
>
> A question is whether this should be in alsa-lib or not. Maybe yes,
> if it's really needed...
Why is Lennart complaining about a 64KB buffer if it is under his control?
On Sun, Feb 22, 2009 at 3:37 PM, Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
Heya!
As one result of the alsa-time-test testing (see that last mail of
mine regarding broken sound drivers) input I got from folks, I learned
how very different the different distribution kernels actually
behave. They are much more different than i actually assumed.
Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes
scheduling latencies of > 210ms. That is a lot. That is really really
really a lot. Other non-Fedora distributions apparently do
something similar.
The parameters in the glitch-free logic are tuned for Fedora-kernels
that easily give latencies of 5ms or so.
ALSA artificially limits the overall buffer size to 64k (i.e. 371ms on
44100hz/2ch/s16le). That this size is not that much when speaking of
scheduling latencies of 210ms should be obvious.
....
>
>
> Takashi
--
Jon Smirl
jonsmirl@xxxxxxxxx
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
