Video/Audio stuttering when using programs

[SeanCollins]

I have come to notice a great deal of stuttering with media while using webpositive. After a bit of calibration of thread prioritys I have 2 suggestions.

1. all thread in webpositive should be below display prioirty. It seems to make no noticeable difference in page load times, but it massively reduces stuttering playback of media.

2. Media server thread prioritys are to low, most should be at display priority.

As a user I found the experience rather annoying that anytime I loaded a webpage the audio would stutter, and stutter aggresively it did. Mind you this situation is largerly occuring only on older slower cpu's p3 p4 athalon 64 atholon xp. More modern cpus, core,phenom did not exhibit this issue and most of these are multicore cpu's.

This is mostly a tunning suggestion to eliminate stuttering audio video playabck while using webpositive.

Thank you for your time.

[ttcoder]

I'll have to experiment on that one, it would be very interesting to see whether it goes beyond just W+, and finetuning only the Media-Server priorities would suffice.

[SeanCollins]

I went and cleaned out the curl.cookies file. Improved performance of webpositive, I noticed that the file size seems stuck to 206.44kb however. cleaning out this file seems to have helped

located boot/home/config/settings/webpositive

is this worthy of a seperate ticket ? it would appear that webpositive cannot make the cookie file bigger then 206.44kb, which seems to massively degrade the performance of webpositive.

[anevilyak]

The cookie file is controlled entirely by libcurl internally, Web+ itself has no real influence over it. In any case, the libcurl backend will eventually be replaced entirely via the services kit, so it's probably not worth filing a ticket over since it's unlikely to be fixed anyways.

[SeanCollins]

Replying to anevilyak:

The cookie file is controlled entirely by libcurl internally, Web+ itself has no real influence over it. In any case, the libcurl backend will eventually be replaced entirely via the services kit, so it's probably not worth filing a ticket over since it's unlikely to be fixed anyways.

Understood. thank you for the feedback.

[ttcoder]

Found out that StyledEdit works even better than W+ to hammer (and I do mean hammer) the Media Server, with the most simple of test cases: whenever I open a 3 MB textfile (e.g. 2 weeks worth of nVidia driver full-enabled logging), it takes several seconds to open in StyledEdit and the audio gets badly hammered for these few seconds.

/me thinks it would do justice to this ticket to change its 'component' from apps/W+ to MediaServer, since it's the lowest common denominator to audio glitches we see here :-)

[SeanCollins]

Done. I tried that as well, that absolutely aweful. I wonder if this is related to the Tickets and patchs Pete Goodeve has been submitting ?

[ttcoder]

Tried for the first time to actually tweak priorities using ProcessController and -- oh boy !!

The audio playback didn't skip a beat, even while opening a 3 MB file in StyledEdit and loading badass pages in W+ and switching workspaces back and forth as some (stress) icing on the cake!

And in case Pete is following this: the "Received buffer .. late" syslog messages stopped once and for all, at least in the half-hour (and counting) of my test here.

Now that is what realtime audio should be like 8-)

Will continue tweaking, trying to find out exactly which thread(s) need fine-tuning; in today's test I just bumped all the +10 up to +15 (display priority, as suggested by Sean); initially this failed to improve audio, for so long as I was still in the Media-Server realm, but as soon as I did the same for MediaPlayer, that's when I got the rock-solid audio described above.

[SeanCollins]

So, several applications and the media server itself need threading priority adjustments. Are you capable of producing a patch ? I am not. I do not have the required skills to produce a patch to adress the issues here. Thank you for the additional diagnostic work on your end !

[ttcoder]

Dang I'm fairly annoyed as I've refined my 'torture test' to be more brutal and now I can't get flawless audio any more: even if I rise priorities to +20 audio is "close but no cigar", i.e. I can get glitches if I try hard enough.

The refined test is to open the multi-MB textfile, and then drag/hover the (still loading/layout'ing) StyledEdit window over a bunch of Tracker windows. @Sean I guess you'll see the same behavior I see with this test too?

Tracking down where each thread is created takes some time, the MediaPlayer app is surprisingly big, but if 'patching' its source does not even fix the problem then I guess it's back to the drawing board for us :-/

One of the two interesting MediaPlayer threads is a BLooper created ​here ..

I guess one could change it to no longer use the default parameter but instead override it like thus:

	PlaybackManager::PlaybackManager()
	    :
	    BLooper("playback manager", B_DISPLAY_PRIORITY),

and track down the other loopers/threads to do the same, but again that would just bring performance to 99% level, not to perfection..

To get the remaining 1% of glitches we'll need someone more savvy coming to the rescue!

P.S. Also tried SoundPlayTT and out-of-the-box playback is a bit better than MediaPlayer, but still not perfect, around 95% good or something. Playing with the "priority" slider in prefs/playback helps a little, just like playing with ProcessController's menus helps a little in regard to MediaPlayer...

[stargatefan]

Replying to ttcoder:

Dang I'm fairly annoyed as I've refined my 'torture test' to be more brutal and now I can't get flawless audio any more: even if I rise priorities to +20 audio is "close but no cigar", i.e. I can get glitches if I try hard enough.

The refined test is to open the multi-MB textfile, and then drag/hover the (still loading/layout'ing) StyledEdit window over a bunch of Tracker windows. @Sean I guess you'll see the same behavior I see with this test too?

Tracking down where each thread is created takes some time, the MediaPlayer app is surprisingly big, but if 'patching' its source does not even fix the problem then I guess it's back to the drawing board for us :-/

One of the two interesting MediaPlayer threads is a BLooper created ​here ..

I guess one could change it to no longer use the default parameter but instead override it like thus:

	PlaybackManager::PlaybackManager()
	    :
	    BLooper("playback manager", B_DISPLAY_PRIORITY),

and track down the other loopers/threads to do the same, but again that would just bring performance to 99% level, not to perfection..

To get the remaining 1% of glitches we'll need someone more savvy coming to the rescue!

P.S. Also tried SoundPlayTT and out-of-the-box playback is a bit better than MediaPlayer, but still not perfect, around 95% good or something. Playing with the "priority" slider in prefs/playback helps a little, just like playing with ProcessController's menus helps a little in regard to MediaPlayer...

snip, Fixed

[SeanCollins]

Sorry about the above response, Stargatefan works for me part time and apparently left himself logged into trac on my computer. Awesome. So thats actually my reply. I'll have to have him clean that up tommorow.

[ttcoder]

@SeanCollins, want to weigh in on #8007 ? Pete and me only have access to single-cpu 'puters, but maybe you can add broader experience/data, maybe dual-cores ..etc ?

People don't seem overly enthusiastic at trouble-shooting these related (?) tickets despite their severity, so I'm trying to mobilize folks :-)

[Giova84]

I still have these issues: https://dev.haiku-os.org/ticket/8136#comment:5 (and my ticket could be a dup)

[jua]

(In #8136) Yes, serial debugging may be a problem, try to disable that (see my comment from today on #8007 how to do that).

Otherwise, this might be fixed by some upcoming MediaKit fixes which I will commit soon (next 1-2 weeks maybe).

Closing this ticket as duplicate of #7882, please continue discussion there :)

[Giova84]

Replying to jua:

(In #8136) Yes, serial debugging may be a problem, try to disable that

Also if i disable the serial debug output, the situation is always the same.

[pulkomandy]

Hi, Did the #8007 fixes and the new scheduler improve the situation here, or are there still problems?

Also, part of this may be caused by:

• The serial debug
• The kernel being built in debug mode in all releases until now

If you need better performance, a release mode kernel without serial debug may help.

[ttcoder]

With a year of perspective on this, the tiny glitches on our dual-core production platforms seem to be gone, and maybe also the bigger ones on my old AthlonXP (only using it for a few minutes every now and then, no serious testing these days..). Unsubbing. Giova could try R1beta1 when it's out, in case the "release" build profile helps indeed..

[pulkomandy]

Even the alphas have been using a debug kernel. Serial output is disabled there, however. Currently the only way to get a release kernel is to compile it yourself. The debug one has a lot of "paranoid" checks which helps catching a lot more issues and debugging them more easily.

[Giova84]

Hi, unfortunately I no longer have this old computer, so I can't test anymore this issue. In anyway that computer was an Acer Veriton 9100 (specs here: ​http://www.cnet.com/products/acer-veriton-9100-p4-1-4-ghz-128-mb-40-gb/specs/ ) upgraded to 256 MB of RDRAM. So, if someone has a similar computer, maybe could try with a recent nightly build.

[SeanCollins]

I recomend closing, the scheduler updates semmed to have helped, I still see issue with heavy disk IO however, but thats a seperate issue.

[kallisti5]

agree. The scheduler change had a lot of performance impacts. Re-open if issues still seen.

[Giova84]

hrev51713 gcc2h, Haiku on an old Laptop (with a Celeron M @ 1,50 Ghz): I still encounter this issue, especially while browsing: the audio (wav and mp3 files) from any app will stutter. By using the app "Slayer" from HaikuDepot ( A tool to manage teams and threads), if I increase the priority to media servers, the stuttering is more reduced. previously I had Windows XP on this laptop, and I didn't encounter the audio stuttering (obviously I just play plain audio files, not HD videos :-)

EDIT:

If I increase priority also to media players (bundle MediaPlayer or Qt player), the stuttering totally disappear.