Another round of tweaks to ALSA parameters to fix reported regressions with HD audio passthrough. @fritsch reproduced the issue and tested these fixes.
AE: ALSA: Try to get 200ms buffer even if we did not get 50ms periodsize
AE: ALSA: Try to get a minimum of 4 periods per buffer
@sjongele: Please give those a try, as you found the issue.
@vicbitter: Also do so, please.
It works for me and I am feeling quite confident, that we get our goal done: Larger periodSize, adapted to the sampleRate and enough buffer to not run into underruns, while keeping menu sounds working.
will test the proposed changes tonight and communicate results.
Based on a few test tracks, the combination of the two seems to work well; the log remains clear of underruns. Just the first patch is not enough.
I am still getting under-runs, doubling the buffer sizes fixes the issue for me. Also I do not understand the comment that states that 'Buffer will be increased after those are fixed' with regards to menu sounds. What needs fixing about them?
I am configured for 7.1 LPCM with output stereo to all speakers enabled. Under-runs occur every 1-2 minutes.
I am wondering if we ever get this right without a dedicated thread which feeds the output buffer. In case of PA there's another thread/process involved as well.
@gnif, since buffer size should not be smaller than before the changes, I guess it is the lower period count that causes issues for you, since this results in a smaller number of frames in "non-active" periods. Enlarging the buffer (as you tried) would be the preferable solution to this, but unfortunately this causes too much lag in menu sounds. Do you have a log (of failing case at least, preferably also a log with an older working version), to confirm my suspicions and rule out other bugs?
In any case, can you see if anssih/xbmc@5e7278f fixes the issue (instead of doubling buffer size)? If not, I'd really like to see both of the logs I asked :)
As for your second question, currently menu sounds have a lag corresponding to the buffer size if the stream was already running when a menu sound was triggered. This is because the buffer is full of silence that will be played out before the menu sound. This does not affect the first menu sound, since there is no silence in buffer yet. AFAIU this issue is avoidable (by skipping over the silence by some means), though I'm not sure of the best/correct approach yet without further investigation.
I am not so sure, there exists a correct calculation for all hardware, that works perfectly. If we calc sampleRate by 40 - it is already pretty low, perhaps lower than the minimal periodSize of some cards. Really low periodSize causes interrupts quite often, which does not scale on some hw. The pivos for example had a problem with the periodSize too low ...
The original implementation had periods of 16, used a max of 8192 frames buffer and calced the periodSize by buffer / 16 which is 512 (in the max case). For 48khz content, this is approximately 10 ms which is quite low - as said too low for the Pivos.
I think lowering the periodSize will fix it again for @gnif, but will break it for @davilla.
It is not so easy for this thread to go - as the whole concept of the - i call it "main running" thread also has to be changed, cause it is considered non blocking, while called from outside ... the implementation is quite hybrid, so non blocking in theory, but blocked by self started events and so on ...
@fritsch I believe halving periodSize once more will likely not yet break it for @davilla (though of course it is possible), since the period count is still 8, while original was 16. Of course this makes the periodSize smaller than really necessary for us, but since we can't feasibly use a larger buffer instead due to menu sounds ATM...
I though a bit over the night and I would go another approach. For now we just have a linear model with two fixed parameters concerning buffer and periodSize. We limit the buffer because of the menu sounds, which is bad itself - cause of sacrificing "perfect" playback only because of some stupid menu sounds.
But - as menu sounds are played with 44100 or 48000 hz, we could use this and incoroporate a hz depending factor, e.g.
bufferSize = periodSize * 4 * std::max((sampleRate / 44000), 1);
That way we can have more buffer for the bitstream formats, but keep it "quite low" for the normal stuff. Perhaps - if your latest patch still works for all - a combination could be useful.
If this does not improve the situation, we have to say goodbye to the linear model and think of something polyonmical after we have identified the constraints. I see a advancedsettings coming up :-)
@anssih I did some testing over the weekend and found that you are correct, this issue was occurring on the old code also, wife uses the TV more then me and as such she never brought the issue to my attention. I just noticed it when I did some updates to my network and as part of it, updated XBMC. Also, doubling the sizes did not fix the issue, just reduced it.
As for the samples for GUI sounds, AE injects them as late as possible into the stream, that is why they are pre re-sampled and pre up/down mixed. IIRC SoftAE then takes these samples and mixes them in right before the buffer is passed to the sink, so I am not sure how you can reduce the delay any further.
FWIW the WASAPI sink runs at 50ms by default and on a P4 here, and I've run as low as 15ms on a decent AMD A6, so GUI sound latency is not much of an issue if the final output buffer can be kept to a minimum. That's basically total output buffer, not multiplied by some further factor like periods * period size. ALSA's async and WASAPI's IRQ-driven, so obviously different methodology, but @gnif is right - the sounds are mixed at the last possible moment, so unless it's possible to let ALSA mix them or can drive the ALSA buffer size down you're in a damned-if-you do position with those....
Just to chime in: I'm using an Atom N330 with Ubuntu 12.10 here and I'm still getting occassional buffer underruns with ALSA when playing with PAPlayer, especially near the end of songs when eg. stuff gets written to the log. I really think we need more buffering no matter what...
@arnova - is it 5 seconds before the song ends? And is it especially noticeable when changing sample rates / channel count (e.g. mp3 to 24/96 FLAC)? That's a different issue if so (meaning outside of the sink level and external buffering).
@DDDamian: Well it's indeed about 5 seconds near the end of the song but no change in sample rate/channel count is at play here since all my songs are 44KHz 2 channel MP3.
@arnova - yep - try as above with a change of sample rate etc it's double-whammy as a lot of pre-buffered stuff gets dumped as the masterstream gets changed and the sink re-inited. It's not a quick-fix - much of the engine needs a re-write to counter that. But what you describe (mp3 > mp3) is largely processor speed / buffer size dependent atm. Things get locked up badly as the file / stream buffers fill and the decoder works. Output buffer size is a countermeasure but not the full solution.
Sorry for the off-topic.