[fritsch]

Yeah, that was it. Okay, then that's clear.

[FernetMenta]

It does, if vfs has an issue with returning / fetching small values ... and it seems it had an effect.

please point to the the location in the code where PACKET_SIZE is passed to vfs. I am curious

[FernetMenta]

It looks like setting buffermode=1 is fixing my issue, so I think the current issue I have is just down to the pretty high bitrate of the file (6Mbit/s), the limited buffering in paplayer and my not-great network (I'm going through a wireless bridge at the moment).

Any other way of increasing buffering in paplayer?

There are more users here who have buffering issues with paplayer that are fixed with buffermode=1.
One reports he has buffering with lossless music, but can play Blu-Ray without buffering (this is with a NUC using wifi). So it might be worth considering increasing the buffering paplayer has by default.

There is no dvdplayer like buffering in paplayer. I don't think it makes much sense to implement this. Maybe we should make buffering set by buffermode configurable by players.

[fritsch]

It does, if vfs has an issue with returning / fetching small values ... and it seems it had an effect.

please point to the the location in the code where PACKET_SIZE is passed to vfs. I am curious

There was a sadist talking with a masochist. And the masochist asked: "Please, come on, beat me up!". The sadist answered: "Nope!".

[popcornmix]

Added to config.txt:
hdmi_mai_thresh=0x1412
Play in file mode, no browsing
1 drop (@~10 s) during 4 minutes
Then change to full screen and no browsing for 4 more minutes
No drop

Can you remove hdmi_mai_thresh and add

Code:

hdmi_pixel_freq_limit=400000000

And report if it's better/worse?

[MrNice]

@popcornmix

Changed back start.elf and fixup.dat from build #0328
Removed from config.txt:
hdmi_mai_thresh=0x1412
Added to config.txt:
hdmi_pixel_freq_limit=400000000

Play in file mode, no browsing for 4 minutes
3 drops (@~5s-15s-3.5mn)
Then change to full screen and no browsing for 30s more minutes
Plenty drops every second
http://xbmclogs.com/pywdlzx7z

[arnova]

Are we sure this is an actual VFS issue? Note that stuttering issues with PAPlayer are NOT entirely new. We had several issues with it in the past: first with Xbox, and later on again when (Soft)AE got implemented. I find it not surprising that "some" filesystems *may* be slow when reading with arbitrary packet-sizes (as an example take the caching issue I recently fixed with Curl+FileCache). I also always found it surprising that PAPlayer didn't have any internal buffering like dvdplayer has.

[popcornmix]

Are we sure this is an actual VFS issue? Note that stuttering issues with PAPlayer are NOT entirely new. We had several issues with it in the past: first with Xbox, and later on again when (Soft)AE got implemented. I find it not surprising that "some" filesystems *may* be slow when reading with arbitrary packet-sizes (as an example take the caching issue I recently fixed with Curl+FileCache). I also always found it surprising that PAPlayer didn't have any internal buffering like dvdplayer has.

No, I don't there is any evidence of a VFS issue. fritsch suggested that based on a misunderstanding of my comment (he read my comment as saying changing the block size improved things, but my intention was to say it didn't affect things).

I think paplayer does have very little buffering, which makes multichannel/high samplerate/lossless audio problematic over wifi. buffermode=1 does avoid that (as does forcing dvdplayer which has more buffering).

[fritsch]

I am quite confused a bit, yes. Cause there is still the "issue from local disk" standing which affects my RPi2 when doing >= 96 khz + multi channel. So this is a firmware issue instead?

[popcornmix]

I am quite confused a bit, yes. Cause there is still the "issue from local disk" standing which affects my RPi2 when doing >= 96 khz + multi channel. So this is a firmware issue instead?

Yes, there is also a firmware issue. We can underrun the audio fifo when running >=96kHz + multichannel.
I think this is solvable - the suggestions I gave to MrNice did seem to cure the problem for me, but MrNice still seemed to have issues.
He does have a Pi1, so it's possible some of his issues may be ARM cpu related.

[alexoz]

Hi all, I just registered to say a big THANK YOU to popcornmix as I can finally enjoy 5.1 96/24 audio on my RPi2!

I have struggled with this issue of audio drops since the day I got my Pi2, I had already tried overclocking, forced buffering, local playback, but in all cases I would have audio drops with a rate of up to 1 every 2 seconds. The only "solution" so far was to either manually resample my audio files to 48KHz, or force 48KHz output from kodi.

But, now, with the latest firmware and "hdmi_mai_thresh=0x1412" the issue seems resolved, I just listened to 10 minutes of 6ch 96/24 audio with 0 drops. So thanks again, keep up the good work!

PS: where can I find information on what this option does?

[shadow]

I wanted to report that I was having the same issue with 5.1ch 96kHz 24 bit flac files and updating the firmware and using "hdmi_mai_thresh=0x1412" has fixed the issue.

[MrNice]

I did the update and change in config.txt
Played all my HD test files and more, more than 1 hour from SD and USB hard drive,
And, and... NO DROP at all

You got it all of you are champions.

Many thanks, this will avoid me to buy a new hardware.

[popcornmix]

But, now, with the latest firmware and "hdmi_mai_thresh=0x1412" the issue seems resolved, I just listened to 10 minutes of 6ch 96/24 audio with 0 drops. So thanks again, keep up the good work!

PS: where can I find information on what this option does?

The GPU has a register that determines how samples are transferred into the HDMI audio fifo. The fifo contains 32 words and the hdmi_mai_thresh sets 4 values that affect how data is transferred (through dma) into that fifo. These are labelled DREQLOW, DREQHIGH, PANICLOW, PANICHIGH in the spec (in bytes from lsb end).

Now the spec doesn't make it clear what these do. It appears the dreq ones were more significant than the panic ones. It seems low values underflow more and high values underflow less, but if you get too high you get get glitches. So I've just been trial and error testing and 0x1412 (DREQLOW=12, DREQHIGH=18) seemed to be best.

Let me know if you get any problems with these settings (might be worth testing low sample rates / number of channels too). If no problems are reported I'll make this a default in a future update.

[alexoz]

But, now, with the latest firmware and "hdmi_mai_thresh=0x1412" the issue seems resolved, I just listened to 10 minutes of 6ch 96/24 audio with 0 drops. So thanks again, keep up the good work!

PS: where can I find information on what this option does?

The GPU has a register that determines how samples are transferred into the HDMI audio fifo. The fifo contains 32 words and the hdmi_mai_thresh sets 4 values that affect how data is transferred (through dma) into that fifo. These are labelled DREQLOW, DREQHIGH, PANICLOW, PANICHIGH in the spec (in bytes from lsb end).

Now the spec doesn't make it clear what these do. It appears the dreq ones were more significant than the panic ones. It seems low values underflow more and high values underflow less, but if you get too high you get get glitches. So I've just been trial and error testing and 0x1412 (DREQLOW=12, DREQHIGH=18) seemed to be best.

Let me know if you get any problems with these settings (might be worth testing low sample rates / number of channels too). If no problems are reported I'll make this a default in a future update.

Thanks for the information, with this setting I have had no issues at all with 2/6 channel 44.1/48/96KHz 16/24bit files and I see now it has become the default in the ab9e773 firmware.