oshcar wrote: > quote "It doesn't but if you have to perform an operation on 16 bit > sample (e.g. gain for volume adjust) and then any 16 bit operations > usually ends up with a 32 bit answer" > i dont want to perform any software operations > so why do i have to pad to 32 bit ? In case operations have to be performed on the data (e.g. depends on ALSA device and devices setup). ALSA is the API you are using to communicate with the DAC. It is general purpose. It is a general system, "you" don't pad - the ALSA subsystem pads input samples to 32 bit at the start, it is most efficient as ALSA knows all data is in uniform format and provide maximum accuracy.
> even if i set ALSA f at 16 to drop the LSB later on before sending to > dac ALSA will do whatever is necessary to send compatible audio sample to DAC - if it is a 16 bit DAC ,it will make the samples 16 bit. > -- what do i do if playing a 24/96 file ? -- then i have to manually > change f to 24 every time ? >From Audio file format (e.g. Flac header) squeezelite will open ALSA device with details of the format of the Audio sample (e.g. 24/96 2 chan, 16/48 1 chan etc.) Assuming no resampling needed. ALSA will pad 24 bit to 32 bit internally and when ready to output will send 16bit, 24 bit - whatever DAC can handle. > quote "Use ALSA "hw" devices and ALSA will not do any s/w conversions" > it is my understanding that there is more to this driver setting -- for > example generic 5102 = output setting hw:sendhifiberry -- something like > that --- my understanding is that there is more in this driver placed > there by hifiberry developer --- if you clear this field -- default > values are used -- are you saying the default values are doing some kind > of software calculations ? "hw:sendhifiberry" is the device designation. If you do not specify it the default device will be used. If there is more than one audio device, it may not be the sndhifiberry". The defautl device ios usuall"default:" or "sysdefault:" which may be mapped onto "plughw" or another ALSA device . Use alsacap to show the capabilities difference between devices. Usually h/w supplier develops the driver to interface with ALSA. There is still a lot more within ALSA which user might want (e.g. 1 chan to 1 chan conversion, snoop, mix, resample) With regard to plughw vs hw devices. With "plughw" ALSA make DACs more compatible to input through software. For example, if DAC only supports 44.1Khz - if you try to play a 48kHz file (e.g. using aplay) with the "plughw" - ALSA will resample and then sent resampled 44.1Khz audio to DAC. If aplay uses the "hw" device - the "hw" device will fail to open since sample rate is not supported. > i have no desire to use sox It will be used by LMS if required unless disable in which case incompatible stream will not play. > quote "So if you have a 16 bit input, use ALSA "hw" and have > analogue/external volume control - then within ALSA 16 bit sample will > be changed to 24 or 32bit by adding LSB zeroes in case there is > processing and those zeroes will be removed when output to DAC - if > there was no "processing", the 16 bit audio sample value will be > unchanged from input." > i am confused by this -- i never get 16bit output unless i force with > f=16 ( Rpi driver ) -- this whole chain of events doesnt seem to be what > is actually going on to me > are you saying the 16bit input is being padded to 32bit by ALSA ( not > squeeze code ) waiting to see if any processing happens ( by sox i > assume ) then ALSA again drops LSB to match the value i put in ALSA > setting f ? Give specific exaplanations of the test "i never get 16bit output unless i force with f=16 ( Rpi driver ) " so thatit can be understood. > whatever the case is above -- if i know that i wont be doing any > software conversions --- why do i have to go through all this ? -- this > goes back to my original post --- 16bit in = 16bit out , 24bit in = > 24bit out[/quotye] > Because you are using ALSA which is a general purpose Audio subsystem. > It will not alter audio sample, if there is no need (i.e. mismatch in > input and output device). > > > > > Also -- if i pad a 16bit input to 24bit and send that to a dac that > > accepts 24bit -- have i increased the dynamic range ?> > > No. 32 bits are there for calculations/operations - it has not changed > the input audio sample value. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
