Adjustable stream parameters for HDA driver

[Pete]

The current (fixed) default buffer size in the HDA driver is unsuitable for real-time use, as it results in a latency of 1/10 sec or so. The attached patch makes it possible for the user to supply a settings file (in /boot/home/config/settings/kernel/drivers) that can optionally set buffer size, buffer count and sample rate.

Parameters supplied in the file override the defaults (and the sample rates in the Media Preferences), but any not supplied remain at their defaults.

I find that if I leave the sample rate at the default 192000 fps, but request 4 buffers of 1024 frames, I get a nice 13-14ms latency.

I'm also attaching a sample hda.settings file (as it didn't get into the patch...)

[Pete]

Patch to add settings file to HDA driver

[Pete]

sample HDA settings file

[axeld]

What's the point of overriding things you can easily set in the Media preferences? Unless you can come up with a compelling reason, I would prefer to leave out that functionality.

[Pete]

Replying to axeld:

What's the point of overriding things you can easily set in the Media preferences? Unless you can come up with a compelling reason, I would prefer to leave out that functionality.

I debated that a bit, but there were some things that decided me.

First, the auich settings file has a sample rate setting, so I wanted to correspond with that.

Secondly, if one is using a settings file, it seems much more convenient to have everything in one place. The thing is that the sample rate and buffer size interact, so if you set one, you'll probably want to fix the other, too. The override is shown by all the alternatives in the prefs menu disappearing, so it should be clear.

If you don't include sample rate in the file, it will be adjustable as normal, but to keep latency the same you'd have to edit the file anyway. I considered keeping the buffer autoadjustment with rate, and add some scaling factor, but I decided that would be completely baffling to a user.

Is there ever likely to be much reason to change parameters once they're set up to one's satisfaction? Now I've got my system working as I like it, I don't see myself fiddling with it again soon.

BTW, I've discovered that currently the prefs rate selectors don't work 'live' anyway (independent of this patch). Unless you restart Media Services, you're liable to get grungy or no sound (with the Synth anyway -- haven't investigated e.g. MediaPlayer).

[axeld]

Sorry, that's not really convincing to me, but thanks for elaborating.

I think it would be much nicer to deal with the buffer size in the media preferences (it should try to find good defaults anyway), and either make this available via the good old "real-time setting", or by being able to select different buffer hints (like small/balanced/large). Only if the normal settings do not suffice to get acceptable audio for your needs, the settings file should be needed. We should aim for not needing it in 99% of the use cases and hardware.

However the setting should work live, indeed, but that's fodder for another ticket.

[Barrett]

I agree with pete that there's need to precisely adjust the buffer size when the sample rate change. And not only, ideally also the buffer chain should be fit to this change. This is more important for audio than video, but things may change considerably doubling or dividing by two this factor. Also, while it may seems to make things more easy from a user perspective having "small/balanced" etc. settings isn't helpful in any way. At certain levels there's some special value that makes the good balance between latency, quality and system load, and this will change considerably varying the hardware.

So my opinion is that we should have a configurable buffer size parameter, and the possibility to set a preferred size of a chain (maybe depending on the format) should be seriously investigated. If the functionality is still seen as a surplus for the end user we should consider to add some "Enable advanced configuration." option with the needed warnings.

[pulkomandy]

I see two things to improve:

• This problem is global to all sound card drivers, so a solution should be implemented on Media Server side instead of a separate setting file for each driver
• It should be possible to guess a "good" buffer size. I think we have a size defined in bytes for the buffers now, we should define the size in microseconds or so, so changing the sample rate would not need adjusting the buffer size.

I owuld try, as much as possible, to make this "just work" by computing a reasonable buffer size. This means, no user-visible settings in media preferences. But advanced settings in a settings file is probably ok. Or, something accessible from the Media Kit API, so apps can adjust their own settings as needed (I would think the needs are different in different uses, for example MediaPlayer vs some MIDI driven synth).

[Barrett]

I think the first defect of the media_kit is to try to guess more things than it should, i am referring specifically to latency in this case but this may apply also to buffer size, this should be the first thing to take in consideration for a media2_kit.

Returning to the argument, while the end user rarely will have to do with Media preferences parameters, another kind of end user will be hungry if he don't have the possibility to balance such values. This is for a number of reasons, it's long to explain precisely but depending on which part of audio production you are doing (recording, filtering, editing, mastering, post-production) you might have reason to have different values and possibly this should be changed in real time without the need for a reboot of the system. That's why i think those should be in preferences with some level of automatic configuration, just like we have in other parts of the system as Network preferences. By default the system may ship automatically configured and the user will have the possibility to choose personalized values if he want.

There is also possibility to get some points of the media_kit to better calculate how many BBuffers to get added in the BBufferGroup starting from the number of buffers of the end audio node, for example in AudioMixer::FormatChangeRequested there's a TODO that say "we might need to create more buffers", in this case we should always take into account the final chain size to calculate the number of buffers of the BBufferGroup. I don't think Haiku should understimate the value of this level of configuration if the project is really interested to make it ready for production. More like when building musical instruments you should be a musician to understand some things such as a well-done neck, in this case you should go on the other side of the microphone to understand why those values are so important for a general purpose device.

[pulkomandy]

There are two very different use cases here. One is "I want to listen to music using MediaPlayer", and the other is "I want to use Haiku as a music production/recording station".

We can do both, but I think the default media preferences shouldn't expose all the settings to the user. It's meant to be a simple mixer to adjust volume of different apps, and that's it.

There is a need for a more complex configuration for the second use case. I think it should be in a separate place. A settings file or API is a good way to start, because it allows a 3rd-party (or not) app to plug into it and add an UI to make the changes. It could be Cortex or something similar, it could be each app using the Media Kit, or it could be the user and a text editor. And it could even be the Media prefs, if we manage to integrate it in a way that doesn't make it look like a profesional audio mixing device with lots and lots of knobs all around.

[Barrett]

Take OS X as example, it's born to be both for users and production people, but this doesn't prevent the OS to satisfy both. I think the real win of an OS is when your software is good enough to be general purpose. In more pratical words i mean that you should be able to open the PC and paint any color you like. I agree that that the driver API and something user level should be implemented, but i am still convinced that it's really boring for someone interested in calibrating the system to edit a text file. It looks like we want to be less "linux-way" by hiding some very important settings, but we then force the user to go in a text file.

What is the general opinion around adding add-ons support to the Media preferences and leave this kind of advanced things to optional add-ons provided in the package manager? This could be a interesting solution to the problem potentially satisfying everyone. I think it could be made also so that you can have some nodes in the preferences by default using parameter webs, this is what we are already doing for the mixer. For example the equalizer might be a desiderable feature to have at boot.

Relating having the functionality in the Media prefs, we aren't talking of a dozen of knobs but just two more controls (buffer size and chain). If we consider to add something more configurable, such as type defined settings i think there's only a BMenu to be added. But i think the preflet add-ons might be the best for extending the os in ways that aren't the default mission of the OS.

[pulkomandy]

​https://www.haiku-os.org/blog/axeld/2005-11-08_mmmh_fonts sums up well my view on adding advanced things like this to the default preference panels:

" have you ever changed the cache settings there? Have you felt good about it? Did you know what you were doing? Did you notice any change? If you're like me, you can answer with a honest "no" to most of these questions. "

I agree there is a valid need for adjusting these settings in some use cases, but for a non-technical user they can be very confusing. So we must make it clear what are the normal things to adjust (relative volume of different apps), and what should not be touched unless you know what you are doing (buffer sizes, mixer algorithm choice, etc). Maybe the same preference panel can be used, but we should think about how to make the separation clear (the advanced settings should be one level "deeper" than the system mixer).

You are taking OSX as an example. Let's see how it's done there. There is a "sounds" preference:

​http://cdn.redmondpie.com/wp-content/uploads/2012/08/MacSoundsStep4.png ​http://recomhub.com/blog/wp-content/uploads/2015/02/Yosemite-system-preferences-output1.jpg

There you can select one device and adjust volume and balance. Simple and easy.

Then there is "audio devices": ​http://recomhub.com/blog/wp-content/uploads/2015/02/Yosemite-system-preferences-output1.jpg

In this other panel, you can adjust all advanced settings (but still I see no buffer size parameters)

[Barrett]

Because under os x there's not a media_kit like ours in philosophy and purpose. There's not something taking into account basically all problems into one system server and the decision was to make able the final apps to configure their own graphs. Any AudioGraph is forced to use the same buffer size. But any plugin host, such as a recording software but not limited to, will provide you this functionality, and the media_addon_server is a plugin host. Otherwise there's not point in the whole media_kit since it's provided with the purpose to unify the most of things. When jack run under OS X, it's easy to get os x native apps to appear as jack clients. In Haiku it's bit more difficult as you have two very different graphs with different rules.

​https://support.apple.com/it-it/HT201530

I think the user could just be able to add any node into the system preferences so that it will be here always. It may be the equalizer, there may be different need and want it on the input or the output or both. Since it's a minor functionality, i think the preflet could have something to make it able to do that, selecting inputs and outputs, so that the media_server on boot set up the equalizer behind the AudioMixer. Once there's support into the system API it's matter of adding an Add button and a configuration window from the user perspective. For user apps some other functionality may be provided, for example once jackd is running reasonably well we can have an optional plugin to replace QJackCtl. Jack could just override the settings that it can, exposing only custom ones to the user.

[humdinger]

I moved an updated patch that now applies cleanly again to Gerrit: ​https://review.haiku-os.org/c/haiku/+/521

Hope it'll get merged. Musicians would be happy to have a workaround instead of 1/10s MIDI latency...

[korli]

Patch applied. Media preferences settings are still considered, I'm not closing the ticket for this reason.

[pulkomandy]

Removing HDA audio tickets from Beta2 milestone, no one has worked on it and opensound is available at least as a stopgap.