soundcheck wrote: > > 1. > Interesting to see that you looked already in SCHED_FIFO scheduling for > squeezelite. > If you run the "output" ?? thread SCHED_FIFO, what priority do you > assign? > FYI: My favorite audio app -- ecasound -- offers an external prio > parameter to set the priority of its internal processing thread. Have > you thought about it? > (UPDATE: Just found the SCHED_FIFO priority parameter in output.c > hardcoded to default 40 - you might increase at least to a level > 50 > like done with jive_alsa in EDO) > Yes it's currently 40. Touch by default (and with EDO) uses 45, portaudio uses 1. It's only really relavent in the context of all the other FIFO priority tasks and I was originally thinking that we would be running on systems which mainly use SCHED_OTHER, so the absolute number would not be too relavent. I don't see a downside of boosting it to 50 on that basis.. (Note EDO only changes the priority of the tasklets for the kernel drivers as its more important that the usb tasklet runs than the application runs otherwise the dac will get starved of data)
> > 2. > I'm wondering if the volume can be locked at 100%? Respectively, if the > whole volume control mechanism can be turned off? If not - would you > consider t introduce such a function? > It should be fixed if you set the server settings to set volume at 100% and also disable replaygain. In this case the code to compute the volume scaling is bypassed - if you look at output.c it always has two cases, one for with volume and one without. The 32 bit signed case is most optimal as it's just a memcpy in the output process. > > 3. > Bit depths formatting: Is it meant to allign the DAC and Alsa to avoid > e.g. plughw. > A DAC that would e.g. accept S32_LE only (e.g. WAVE-IO), would have to > be set with -a f=<32> to avoid plughw. > Or. The Touch SPDIF driver accepts 24bit (4bytes) S24_LE. If f=24bit is > chosen I can avoid plug. Is that correct? > If you use hw:* as the device name then it will try to open it without any resampling and with the appropriate format for the device. If the sample rate is supported by the device then it opens the hardware natively. If it is not then it reopens a device called hw:* as pluginhw:* to get resampling. However it will go back to hw:* as soon as the sample rate changes to something which is supported natively. It uses the following format order of preference 32S, 24S, 24_3S, 16S. You can force this too with the 3rd param of the -a option: "-a ::24_3:" for instance. Normally USB dacs will be 32S for UAC2, 24_3S for 24bit capable ones or 16S. The only reason I added the preference setting is that on some platforms, such as Pi there were concerns that although the device opened at high bit depths, audio quality was compromised - I think this is really down to the usb problems on pi rather than anything else, so should not be necessary on other platforms. So to confirm the format of the -a option it is: -a <b>:<c>:<f>:<m>, where b,c,f,n are either nothing or integer values, the format option is. So to force the format only: "-a ::32:". Its always worth adding "-d output=debug" to see what is actually happening while you are changing parameters. ------------------------------------------------------------------------ Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
