Op 21-12-12 18:44, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
> Maarten Lankhorst answered:
>>> [...] I wonder why you
>>> insist on using GetStreamLatency as the basis of your timeout
>>> computations instead of GetDevicePeriod.
>> Because I'm using it later on in the rework to tell how much to queue.
> Ah. But why not use the correct tool for the correct job?
> GetPeriod for period, and StreamLatency for buffer and queue sizes?
Because the timeout is not meant to be something that normally should
ever be hit normally, it's just an upper bound on how long we would be
prepared to wait in case something does mess up.
>
>> In my rework, I try to write at most 3 * GetStreamLatency, so even if for
>> some
>> reason no event is ever delivered, you would never get an underrun.
> I'm sorry to disagree, but I've conducted numerous tests last night.
> The results are very disappointing, but I'll only find time in January
> to write more about it.
>
> Basically, no trick in DSound or Winmm whatsoever can prevent an underrun.
> The typical Linux machine can and will not schedule arbitrary threads that
> are ready to run, and I observed arbitrary pauses of 12-120ms. :-(
>
> How much was wake up delayed? For lovers of histograms: sort -n delays | uniq
> -c
> period 20ms10ms
> 57 0 828 0
> 41 1 202 1
>2767 2 2771 2
> 541 3 185 3
> 258 4 1956 4
> 6 5 16 5
> 22 6 13 6
> 5 71 7
> 1 8 10 8
> 2 92 9
> 11 10 3 10
> 4 11
> 1 12 9 12
> 1 13 1 13
> 2 14
> 1 16
> 1 18
> 1 34
> 1 88
> 1 119
>3716 samples 6005
>
> - Even if mmdevapi SetEvent's your thread, there's no guarantee that
> it gets scheduled without or with little delay.
> - Above data is for one thread. As multiple threads are
> involved in producing audio, delays accumulate.
> - Even if the DSound thread always gets to run and Release's data, there's no
> guarantee that the winealsa.drv thread does and sends data to ALSA.
> - Worse, even if the winealsa thread gets to run, there's no guarantee *AT
> ALL*
> (and I've seen it happen) that it won't lose CPU for over 20ms even if
> calling
> nothing but snd_pcm_* (and TRACE) in the callback.
>
> As a consequence, the current winealsa.drv can, by design (ALSA buffer holding
> no more than 3 periods), not prevent underruns, no matter how much you kick
> it.
It's holding 8 periods, it just refills a maximum of 3 periods at a time.
With a timeout upper bound of 2.5 periods, it would keep up on average
even if nothing is moving forward..
> You advertised RT priorities. With them, the picture would look different of
> course.
> A faster machine helps too...
I never looked at winealsa, I'm scared by the memory allocations in dsound
inside
the mixer thread, instead of just allocating some upper bound,
so I never wanted to see closely at how the rest of the stack behaves..
Not sure what winealsa thread is actually doing, but it should really just do
as little as
possible, and if it keeps any locks, all other paths that could end up taking
the same
locks should be audited in a similar way with suspicion.
Even if it's not actually elevated to rt , it should act as though it is, since
any improvements
also benefit upper bound without -rt..
> In January, I'll write more, e.g. about concrete changes in code.
>
> BTW, yesterday I replaced the timer queues in winealsa with an own thread.
> Timing is much better, but that doesn't prevent delays. More changes
> are needed to improve the situation.
>
It would also be interesting if you have any suggestions on how to improve
winepulse,
and if there are still outstanding differences wrt to native mmdevapi. With
that latency fix
I may look into enabling exclusive mode again, as it was probably hit extra
hard by
that pulseaudio bug.
~Maarten
