Oss4 jack proaudio

Question

Hi All,
I'm running oss4 but my 8 year old son is becoming interested in softsynths and sequencers (I'm mostly interested in non-sequencer, qtractor and amsynth). The standard qjackctl doesn't produce any sound on my system. I guess that I would have to rebuild jack with oss enabled although the standard qjackctl has an oss option. Is this the old oss or the new oss4? Is it worth it? I read that oss4 has superior sound but I can't verify that because I can't truly do an AB comparison, by the time I switch from alsa to oss4, my beer may have changed from English to German (cited as one of the major causes of listening bias by a major audiophile magazine).
http://www.roger-russell.com/truth/truth.htm
http://www.roger-russell.com/wire/wire.htm
Question, can I get qjackctl, non-sequencer, qtractor and amsynth to play nicely together with oss4? Is it worth it in 2014 or should I just switch back to alsa? Please chime in, all opinions welcome!
Thanks!
Oh yes, I have some fairly high end equipment, nad, hafler and klipsch.
Last edited by Frabato (2014-08-02 04:26:33)

Answer 1

sekret wrote:That was one of my main reasons as well. But then I found out that the main issue with alsa is dmix, the software mixer for alsa, which is said to have low quality. Pulseaudio for example replaces dmix and provides better sound quality and more features. The same with oss4, which has higher quality software mixing.
Dmix has maximum 24 bit resolution for mixing. So that is one aspect. Or do you also mean the mixing algorithm? Can you pinpoint to the troubling part?
sekret wrote:But if you want high quality audio playback, you can simply not use dmix. For example I use mpv for videos and moc for audio. In mpv you can do it with mpv --ao=alsa:device=[plughw:UA25]
No offence, but using plughw is futile, since it will resample if necessary*, therefore degrading/modifying original signal. Set the appropriate parameters either through custom pcm devices of type hw or create a new hifihw device that will accept runtime parameters (channels, format, frequency etc.) and change them on between playback. This should be feasible through creative scripting, maybe even without much help outside of alsa. Simply because of courtesy and comfort of changing parameters through device addressing or some anomalies, otherwise using type hw should handle changes on its own.
As for the definition, in case of wanted resampling, a resampler may be specified, either for each pcm definition or through 'defaults.pcm.rate_converter' node. See the wiki and the conversation page, there was a change recently involving speexrate resampler.
sekret wrote:
All you lose is, that those applications run like this will block the audio device for other applications. E.g. if I play music in moc and want to play a video with mpv, I get this output
[ao/alsa] Playback open error: Device or resource busy
[ao] Failed to initialize audio driver 'alsa'
Could not open/initialize audio device -> no sound.
You can avoid those errors by specifying 'nonblock 0' into the type hw pcm definition or 'defaults.pcm.nonblock' node. Depending on the sound source, it might play afterwards.
I would recommend using best possible parameters for the jack server with hw:cardname-reference instead of plughw.
Edit: * Unless it is necessary for your hardware, which could be the case. Again I am not trying to flame. Just make sure you understand what plughw actually does, otherwise you might be unknowingly thinking, you are using the best settings. Check 'less /usr/share/alsa/alsa.conf' for more information and our alsa wiki. At some point I will probably add advanced configuration with custom runtime parameters, so it will be explained how they work.
Edit2: Typos, but there are probably more.
The plug pcm in between pcm.default and pcm.jack could be expanded, since it will also resample "willy nilly", unless specified. The best way is of course to have a signal path without conversions and use jack directly.
Last edited by emeres (2014-08-03 15:59:57)