2015-03-30, 17:33
Yeah, that was it. Okay, then that's clear.
(2015-03-30, 13:57)popcornmix Wrote:(2015-03-29, 17:15)popcornmix Wrote: 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.
(2015-03-30, 17:37)FernetMenta Wrote:(2015-03-30, 17:29)fritsch Wrote: 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
(2015-03-29, 23:10)MrNice Wrote: 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
hdmi_pixel_freq_limit=400000000
(2015-04-01, 09:54)arnova Wrote: 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.
(2015-04-01, 14:31)fritsch Wrote: 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?
(2015-04-03, 10:41)alexoz Wrote: 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?
(2015-04-03, 20:55)popcornmix Wrote: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.(2015-04-03, 10:41)alexoz Wrote: 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.