Odd. I wonder if we are still at the “great for 2000” latency specs
There is definitely a lot of tuning that needs to be done, it could be an issue in our media kit, our sound card drivers, kernel, etc.
If you get a moment, could you document how you ran through your testing in a bug report? (http://dev.haiku-os.org). I’d like to see if we could benchmark it over time to track how changes to our Media kit impact it.
Yeah, while we are using the latest Webkit engine in WebPositive (thanks to the awesome @pulkomandy!), we don’t have much in the way of graphics acceleration. Our app_server isn’t OpenGL based like most modern desktops, and our 3d rendering is limited to Mesa LLVMPipe (which is faster than BeOS’s swrast 3d renderers, it doesn’t help us if we don’t use OpenGL for the WebPositive site rendering )
Sound issues in the beta and current rev. On my Thinkpad T420 and eeePC I only get audio through one speaker. It seems like both channels are routing to that one speaker. I have played with the graphical audio interface and enabled/turned up all volume bars but still audio goes through only one speaker.
Just out of curiosity: are we still compiling with debug options enabled in the beta images? Removing them (while keeping them enabled for nightlies) could slightly increase performance, latency and memory usage, couldn’t it? (It obviously makes bug-reporting less efficient, tough.)
@kallisti5: Sure, I’ll open a bug report later today.
I should mention that this old laptop is usable for live playing a MIDI piano using Jack and LinuxSampler or FluidSynth with an acceptable ~11ms of latency. Most of the time, and depending on the complexity of the soundfont being used, I don’t get many “xruns” (audible pops when the CPU and/or audio card can’t keep up). This is achieved with a 512kb buffer setting in Jack, and setting everything to high priority and the CPU governor to performance.
With Haiku, I got no “xruns”, even when multitasking, which is impressive. But there are no miracles with an old low-voltage single-core mobile CPU, and if there were no sound glitches it has to be due to a very high buffer. I could also achieve that same behavior (>200ms latency, no glitches) under Linux by increasing the Jack buffer to something like 2048, so I suspect that’s what’s happening under Haiku as well. Is there a user-configurable buffer setting anywhere in Haiku, or is that hard-coded at this point?
@vvill: That’s a good point about the debug code too, that could also be affecting things to a certain degree.
Looks like there’s a auich.settings file if you’re using that driver. For HDA, @Pete Goodeve has a patched driver that uses a similar settings file, see his website at Pete's Software
Would it be possible to pin a core to the audio server and drivers, and prevent other things from being scheduled to it, perhaps even polling instead of being interrupt driven? It would be a pretty big deal if Haiku had a real advantage here in latency over Linux/Windows.
The CPU would then overheat (because it’s polling so it’s 100% busy) and the hardware thermal management would slow it down. Not a good idea anymore in modern systems.
Threads are already softly pinned to CPUs in order to improve use of L1 cache, and you can change thread priorities, even using “realtime” priorities when needed. There is no need to exclude other threads from using the CPU unless you’re really, really short on CPU power.
Yeah but even at base clocks polling may be faster than waiting on an interrupt and then waiting for the scheduler to schedule the task to run and check things etc… so yes it would be power hungry but lower latency I guess another possibility would be scheduling the driver and media server much more often?
Have you done that? Can’t find it on Trac.
Which driver is your machne actually using? As Humdinger notes, I have a patch for the HDA driver that gives me nicely minimal latency by setting a smaller buffer. I play live keyboard very happily.
Hey, @Pete, you’ll be pleased to learn that I managed to get your patch for the HDA driver applied. After only mild opposition , and minor changes, it’s been merged with hrev52343 (see the Gerrit ticket for the discussion).
Haven’t tried it myself yet, I have to confess…
[Edited to add: I forgot a shoutout to @korli for his review and support! ]
Yaay! Many thanks for doing that! (And to Korli for finally getting it merged!)
I see you removed the sample-rate setting. Probably just as well as it was a bit superfluous and seemed to cause resampling hash if there was a mismatch. I haven’t been using it. (And sorry about the bad formatting! Don’t usually mess up my indentation like that…)
[I haven’t been on the forum lately, because Qupzilla was the only Haiku browser that seemed to work well with it, and it suddenly stopped working a couple of months ago. Or, rather, the forum stopped working with it – Qupzilla didn’t change. I’m in W+ now, but the (older) version on my system is severely deficient. Just tried in my newer partition and W+ crashed! Sigh.]
I really just followed korli’s review suggestions…
No problems here on a nightly 32bit Haiku. qupzilla_x86-1.8.9-9-x86_gcc2.hpkg works for me (I think, I mainly use Web+) and while Web+ doesn’t show some icons in the forums, the tooltips reveal what’s where. Not ideal, but whatcha gonna do…
Yeah, I see my copy is 1.8.6 – a bit earlier. All I get with that now is a blank page! There’s obviously nothing there because random clicking doesn’t do anything either. The source has been loaded if I look at it, and all the details show, but no actual screen display! I tried dumping the settings, but that had no effect.
I’m not helped by the fact that Package-Management seems to hate me! [maybe due the feeling being somewhat mutual…] I decided I ought to finally update my ‘latest’ partition to the current beta – which is a chore because it takes a couple of hours on my DSL line. An hour or so into the download – about 7MB into the 41MB main Haiku package – it just terminated with a load failure! I restarted, hoping that pkgman would be smart enough to pick up where it left off, but no such luck. It started over from the beginning with a new ‘transaction’ folder.
This seems to me a major defect. Surely it could check what’s been loaded, and compare checksums, to know what still needs to be done.
And what happens if you reboot with a partial update? I deleted the transaction folders to be safe.
…and things aren’t any friendlier today . I decided to try again, but just getting back to where I was took an hour! Yesterday I carefully used a wired connection to my router, assuming it to be a bit sturdier that the usual WiFi, and today I went to do the same. There was no sign of the nework card in the preferences! WiFi connected to my router, but wouldn’t go to the outside net! Eventually I found that changing the network settings yesterday completely screwed up the ‘interfaces’ file! (The wired interface was deleted [hunh?] and the gateway removed from the WiFi.) I decided to stick with WiFI this time.
]
] I decided I ought to finally update my ‘latest’ partition to the current beta – which is a chore because it takes a couple of hours on my DSL line. An hour or so into the download – about 7MB into the 41MB main Haiku package – it just terminated with a load failure! I restarted, hoping that pkgman would be smart enough to pick up where it left off, but no such luck. It started over from the beginning with a new ‘transaction’ folder.
. I decided to try again, but just getting back to where I was took an hour! Yesterday I carefully used a wired connection to my router, assuming it to be a bit sturdier that the usual WiFi, and today I went to do the same. There was no sign of the nework card in the preferences! WiFi connected to my router, but wouldn’t go to the outside net! Eventually I found that changing the network settings yesterday completely screwed up the ‘interfaces’ file! (The wired interface was deleted [hunh?] and the gateway removed from the WiFi.) I decided to stick with WiFI this time.