Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
paul- wrote: > If you have a medium to large library, the limited memory might become > an issue. Enabling swap, will help. > > A pi3B+ with 1Mb ram, or a pi4 with 2mb will make the LMS interface much > more responsive. just to tie up the tweakers loose ends in my frenzy i had disabled zswap because i looked it up and saw the words "compression" and "additional cpu cycles" and i am an audiophile so enabled zswap, disabled disc swap -- back to default settings there now too gui seems to be fine oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > :) I am always happy to answer genuine questions, but believe me > > - There are a lot of other people behind that project and squeezelite > was created by a really smart dude and it's impressive to see the amount > of other projects it enabled > - I know very little at the end and others, starting with @mherger but > also @ralphy can testify that I've pushed a fair amount of crap code in > LMS, squeezelite and other places (but I'm always trying to improve) well i`m not tweaking anymore. that is one of the reasons i chose rune in the first place. sounded good to me and nothing to tweak. its a bad thing man. its like a drug. from reading stuff on internet my impression of squeeze was that it was the tweakers dream, almost required to tweak to get your sound. i dont know. sox. i see threads that are 4 years old and people still looking for that perfect setting. so i started with that - sox - about a month and a half ago and down the rabbit hole i went this thread i started was probably really just a cry for help. intervention. i needed someone to tell me i didnt need to do this. lol -- i dont know -- i`m not that pathetic. definitely looking for some straight answers though. anyway, i like squeeze, just havent let it breathe yet to get accustomed to it doing that this week today was good enjoyed it alot oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > lol --socrates -- i`m not that smart dude > > nothing sneaky - i was just really wondering -- "how the fck does that > work" > > anyway, i have a rough idea ( very rough ) > > no need to jump through anymore hoops for me > > I`m glad you responded in this thread though > > i always wondered who was behind these projects and if they really knew > what was going on > > i think you are most likely the real deal, so it makes me confident that > you got this under control and i should just let it fly and enjoy it :) I am always happy to answer genuine questions, but believe me - There are a lot of other people behind that project and squeezelite was created by a really smart dude and it's impressive to see the amount of other projects it enabled - I know very little at the end and others, starting with @mherger but also @ralphy can testify that I've pushed a fair amount of crap code in LMS, squeezelite and other places (but I'm always trying to improve) LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > ahah, feels like you're playing Socrates, all this sounds a bit like a > trick ;) > > I'll make a lot of shortcuts : 16 bits source audio gives you ~6dB/bit = > 96dB SignalToNoise - SNR (if I remember correctly your old Vinyl is > 60-70). If you apply soft volume, your SNR will decrease accordingly to > the ratio you apply, i.e. maybe around ~20dB for mid-volume. You might > not lose these if you send them to a 24 bits DAC but don't forget that > now you have an analogue signal which is 10~20 times less (0.05~0.1V > instead of 1V) and then you have to make sure that that this potential > benefit is not lost in the rest of your chain (how much noise it brings > back when amplifying more to get you to a comfortable level). > > So padding does not add anything, there is no extra information created. > Now if you want to transform (divide) the input, for sure we are back to > the initial comment that larger integers are needed for interim > calculation and your 24 bits DAC falls under that. When adding all the > rest will it be noticeably better... oh well, then this thread should > probably move to the audiophile one which is not for me :) lol --socrates -- i`m not that smart dude nothing sneaky - i was just really wondering -- "how the fck does that work" anyway, i have a rough idea ( very rough ) no need to jump through anymore hoops for me I`m glad you responded in this thread though i always wondered who was behind these projects and if they really knew what was going on i think you are most likely the real deal, so it makes me confident that you got this under control and i should just let it fly and enjoy it oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > ok > took me a bit but i think i get it > > what happens when volume is reduced by software if you dont mind ahah, feels like you're playing Socrates, all this sounds a bit like a trick ;) I'll make a lot of shortcuts : 16 bits source audio gives you ~6dB/bit = 96dB SignalToNoise - SNR (if I remember correctly your old Vinyl is 60-70). If you apply soft volume, your SNR will decrease accordingly to the ratio you apply, i.e. maybe around ~20dB for mid-volume. You might not lose these if you send them to a 24 bits DAC but don't forget that now you have an analogue signal which is 10~20 times less (0.05~0.1V instead of 1V) and then you have to make sure that that this potential benefit is not lost in the rest of your chain (how much noise it brings back when amplifying more to get you to a comfortable level). So padding does not add anything, there is no extra information created. Now if you want to transform (divide) the input, for sure we are back to the initial comment that larger integers are needed for interim calculation and your 24 bits DAC falls under that. When adding all the rest will it be noticeably better... oh well, then this thread should probably move to the audiophile one which is not for me :) LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > Think about it the following way: your DAC can do 0..1V and has 10 + 1 > steps, the data it receives are all between 0..10, > > 0 = 0V > 5 = 0.5V > 10 = 1V > > You break the bank and get a DAC with 100+1 steps, > > 0 = 0V > 5 = 0.05V > 10 = 0.1V > 50 = 0.5V > 100 = 1V > > But it still receives data 0..10, so you have to multiply each received > value by 10 to have the same result as your first DAC. This is what (in > that case) padding is: adding one 0 to the right, in base 10, to each > received value ok took me a bit but i think i get it what happens when volume is reduced by software if you dont mind oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > i got an answer the other day saying the extra zeroes dont matter > because there is no information within them > the information not present is voltage ? Think about it the following way: your DAC can do 0..1V and has 10 + 1 steps, the data it receives are all between 0..10, 0 = 0V 5 = 0.5V 10 = 1V You break the bank and get a DAC with 100+1 steps, 0 = 0V 5 = 0.05V 10 = 0.1V 50 = 0.5V 100 = 1V But it still receives data 0..10, so you have to multiply each received value by 10 to have the same result as your first DAC. This is what (in that case) padding is: adding one 0 to the right, in base 10, to each received value LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > i got an answer the other day saying the extra zeroes dont matter > because there is no information within them > the information not present is voltage ? No voltage involved. The no information in them was intended to mean that they dont change the outcome in any way. philchillbill's Profile: http://forums.slimdevices.com/member.php?userid=68920 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > i got an answer the other day saying the extra zeroes dont matter > because there is no information within them > the information not present is voltage ? I think the answer said the zeroes were added for resolution when doing calculations. They do not add information (e.g. do not add more audio details) to the original number but allow calculation to be done more accurately. Each CD quality PCM sample is 16 bits but to do accurate calculation you need more than 16 bits and so 32 bits is used as that is convenient for processing. Information is a odd concept - with the original punch card - the information is the position of the holes - so the card only keeps the holes in place. 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
i got an answer the other day saying the extra zeroes dont matter because there is no information within them the information not present is voltage ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philchillbill wrote: > Maybe padding is easier to understand with a money calculation: > > I have $100. My son has $150. We want to know how much we have > combined... > > I calculate $100 + $150 = $250. > > He's a smart-ass with a scientific calculator so he calculates > $100. + $150. = $250.. He types those 8 extra > zeroes himself and is very proud. > > Guess what? Either way, we have two hundred and fifty bucks even money. > His padding was of no help whatsoever to the calculation, because it > came after the least significant digit. :rolleyes: i dint appreciate your post enough - the decimals do make it clearer --- is that how it is oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philchillbill wrote: > Maybe padding is easier to understand with a money calculation: > > I have $100. My son has $150. We want to know how much we have > combined... > > I calculate $100 + $150 = $250. > > He's a smart-ass with a scientific calculator so he calculates > $100. + $150. = $250.. He types those 8 extra > zeroes himself and is very proud. > > Guess what? Either way, we have two hundred and fifty bucks even money. > His padding was of no help whatsoever to the calculation, because it > came after the least significant digit. :rolleyes: yeah i get that i just remember reading when using another software that if you were going to use software volume control you should pad the bit rate because when turning the volume down you are actually removing bits and reducing dynamic range -- something along those lines i remember it being from what seemed to be a legitimate source, so i accepted it now it seems the padding part is correct but simply because of cleaner maths or something oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > > one question about this padding -- i still plan to A/B that again > sometime but whatever > how does it work with the software volume control > again i could be wrong, and i did most of this reading a couple years > ago, but i read that it is good to pad if using software volume control > because as you reduce volume you are reducing dynamic range or something > and the padding provides a buffer against this > anyone know what i am talking about and provide simple explanation ? Maybe padding is easier to understand with a money calculation: I have $100. My son has $150. We want to know how much we have combined... I calculate $100 + $150 = $250. He's a smart-ass with a scientific calculator so he calculates $100. + $100. = $250.. He types those 8 extra zeroes himself and is very proud. Guess what? Either way, we have two hundred and fifty bucks even money. His padding was of no help whatsoever to the calculation, because it came after the least significant digit. :rolleyes: philchillbill's Profile: http://forums.slimdevices.com/member.php?userid=68920 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
P Nelson wrote: > When I do comparisons I use ABx testing. This means there are three > samples, and two are identical, ie A=x or B=x. I have to determine > which two samples are the same. If I cannot do that, then I conclude my > perception about hearing a difference, or tasting bottle differences in > wine, is wrong. (Sometimes I notice two bottles of the same wine taste > a little different and I can repeatedly pass a ABx test, but sometimes I > fail the ABx test.) > > Your point about listening to the music and not wanting to turn it off > is a good point. Back when the ipod was the big thing, I could not > listen to my ipod for a more than about a hour. The sound was harsh to > me. I had to switch back to simple radio on my car. My current iPad is > acceptable sound while I am driving. > > Sorry for detracting from topic of this thread, but my point is be sure > you are actually hearing a difference when making various changes. I am > not saying you cannot hear a difference, but using the a ABx method is a > better way to validate. your method sounds foolproof. would require 3 identical players i assume. it`s tough though -- the biases. also reading claims about some of this stuff -- sends you down a rabbit hole. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
When I do comparisons I use ABx testing. This means there are three samples, and two are identical, ie A=x or B=x. I have to determine which two samples are the same. If I cannot do that, then I conclude my perception about hearing a difference, or tasting bottle differences in wine, is wrong. (Sometimes I notice two bottles of the same wine taste a little different and I can repeatedly pass a ABx test, but sometimes I fail the ABx test.) Your point about listening to the music and not wanting to turn it off is a good point. Back when the ipod was the big thing, I could not listen to my ipod for a more than about a hour. The sound was harsh to me. I had to switch back to simple radio on my car. My current iPad is acceptable sound while I am driving. Sorry for detracting from topic of this thread, but my point is be sure you are actually hearing a difference when making various changes. I am not saying you cannot hear a difference, but using the a ABx method is a better way to validate. P Nelson's Profile: http://forums.slimdevices.com/member.php?userid=58158 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
ok Paul & Phillippe I`m "trusting the science" still not getting the jab but in this case i`m going to stop self medicating Already sounds better -- lol i`m serious default settings with a clear mind, comfortable with the fact changing all those setting variables, power modes etc is not going to make a meaningful difference. i feel liberated. you should "Sticky" Phillipe`s explanation of the process and scientific answer to my questions all those variables are just too tempting to play with. i listen pretty much all day every day my test for audio equipment is pretty simple -- if i can listen for extended periods without just wanting to turn the damn thing off then its good. if it keeps me engaged then it is great. so far so good again dont want to offend anyone but SOX upsampling what am i missing here ? it really makes me think it is not working properly on my machine because to me all it seems to do is hammer away at the presence range or something -- no matter what settings i put there, that is my takeaway -- all other differences between settings are just a distraction from this bigger issue. when i started to think this was the case -- i focused on a couple albums with some high frequency problems Cannonball Adderly Something Else (RVG form 99 or something ) and steely Dan Katie Lied phasey,splashy symbols on black friday extreme noise at beginning of Autumn Leaves every setting i have tried in SOX basically eliminates both those "problems" - to the point that with some settings i dont really hear symbols at all on black friday if someone wants to argue that those are alias distortions being removed - they should look up and read "katie had a bug" -- splashy symbols were there the whole time -- even on L.P. pretty sure i had that on LP back in the 80`s and pretty sure that is how i always remember that album sounding. seems maybe the chip makers know what they are doing with those cascade of filters -- maybe people should "trust the science" there also if someone wants to post some sox configuration that makes both those songs sound good without completely removing the "problems" i would love to try it also i would entertain any argument that says both those "problems" are actually the result of bad chip filtering - that those are aliases that shouldnt be there -- i`m just looking for the truth I understand people are not interested in accuracy when using sox but the corrupting of the original signal by one simple filter seems extreme to me. one question about this padding -- i still plan to A/B that again sometime but whatever how does it work with the software volume control again i could be wrong, and i did most of this reading a couple years ago, but i read that it is good to pad if using software volume control because as you reduce volume you are reducing dynamic range or something and the padding provides a buffer against this anyone know what i am talking about and provide simple explanation ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Rpi Dac uses the pcm1794a codec driver The generic (same as hifiberry Dac) uses the pcm5102a codec driver. Use the one that works better for you. piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
just want to confirm this is the correct behavior for the 2 relevant pcm drivers -- all default values -- both are outputting sound -- flac file from 16bit cd Rpi /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpirpidac -a 80:4::1 -p 45 -d output=info -f /var/log/pcp_squeezelite.log [09:58:58.244466] output_init_alsa:933 init output [09:58:58.245087] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: any mmap: 1 [09:58:58.284499] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 11025 8000 [09:58:58.421941] output_init_alsa:999 memory locked [09:58:58.422200] output_init_alsa:1005 glibc detected using mallopt [09:58:58.423416] output_thread:682 open output device: hw:CARD=sndrpirpidac [09:58:58.423610] alsa_open:351 opening device at: 44100 [09:58:58.426649] alsa_open:422 opened device hw:CARD=sndrpirpidac using format: S24_LE sample rate: 44100 mmap: 1 [09:58:58.427216] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [09:59:00.095182] output_flush:445 flush output buffer [10:02:55.043599] output_flush:445 flush output buffer [10:02:55.669397] _output_frames:65 start buffer frames: 28800 [10:02:55.669615] _output_frames:153 track start sample rate: 44100 replay_gain: 0 [10:04:23.503987] output_flush:445 flush output buffer Generic 5102 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpihifiberry -a 80:4::1 -p 45 -d output=info -f /var/log/pcp_squeezelite.log [10:17:58.293313] output_init_alsa:933 init output [10:17:58.293927] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: any mmap: 1 [10:17:58.336569] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [10:17:58.468023] output_init_alsa:999 memory locked [10:17:58.468279] output_init_alsa:1005 glibc detected using mallopt [10:17:58.474615] output_thread:682 open output device: hw:CARD=sndrpihifiberry [10:17:58.474833] alsa_open:351 opening device at: 44100 [10:17:58.477891] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S32_LE sample rate: 44100 mmap: 1 [10:17:58.478292] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [10:18:00.196362] output_flush:445 flush output buffer [10:19:07.546828] output_flush:445 flush output buffer [10:19:07.980426] _output_frames:65 start buffer frames: 48384 [10:19:07.980636] _output_frames:153 track start sample rate: 44100 replay_gain: 0 [10:19:50.754545] output_flush:445 flush output buffer so Rpi outputs 24bit and generic 5102 outputs 32bit for 16bit source flac file locking g 5102 driver for 16bit output produces NO sound : /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -p 45 -d output=info -f /var/log/pcp_squeezelite.log [10:25:26.834259] output_init_alsa:933 init output [10:25:26.834837] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [10:25:26.872386] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [10:25:26.949728] output_init_alsa:999 memory locked [10:25:26.949979] output_init_alsa:1005 glibc detected using mallopt [10:25:26.951173] output_thread:682 open output device: hw:CARD=sndrpihifiberry [10:25:26.951364] alsa_open:351 opening device at: 44100 [10:25:26.954470] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S16_LE sample rate: 44100 mmap: 1 [10:25:26.954873] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [10:25:27.038587] output_flush:445 flush output buffer [10:25:27.043472] output_flush:445 flush output buffer [10:25:51.775733] output_flush:445 flush output buffer [10:25:52.056358] _output_frames:65 start buffer frames: 9216 [10:25:52.056573] _output_frames:153 track start sample rate: 44100 replay_gain: 0 [10:27:25.006952] output_flush:445 flush output buffer locking Rpi driver for 16bit output produces sound : /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpirpidac -a 80:4:16:1: -p 45 -d output=info -f /var/log/pcp_squeezelite.log [10:38:16.065076] output_init_alsa:933 init output [10:38:16.065653] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [10:38:16.095424] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 11025 8000 [10:38:16.168522] output_init_alsa:999 memory locked [10:38:16.168775] output_init_alsa:1005 glibc detected using mallopt [10:38:16.170004] output_thread:682 open output device: hw:CARD=sndrpirpidac [10:38:16.170197] alsa_open:351 opening device at: 44100 [10:38:16.173396] alsa_open:422 opened device hw:CARD=sndrpirpidac using format: S16_LE sample rate: 44100 mmap: 1 [10:38:16.173809] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [10:38:16.222121] output_flush:445 flush output buffer [10:39:08.989923] output_flush:445 flush output buffer [10:39:09.515050] _output_frames:65 start buffer frame
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
If you have a medium to large library, the limited memory might become an issue. Enabling swap, will help. A pi3B+ with 1Mb ram, or a pi4 with 2mb will make the LMS interface much more responsive. piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > Im not the maintainer of picore but in general enabling swap is not > going to speed up a system. It might be necessary to make it work, but > by definition you enable ram to be swapped out and in which is a slower > process that if you have everything in ram (see caveat below). > > Now, these are complex systems and I cant talk why the UI seems more > responsive to you, there could have been many reasons like some other > processes not running any more or some processes would be able to > allocate more memory and that would be a better option to have system > swap rather than developer-implemented handling of low memory / > allocation failures. > > Now, squeezelite allocates buffers and if allocation fails, squeezelite > will carp. It will not run with degraded performances, it will crash. > The only case where you might have audio issues resulting of cpu > overload is when the rate of sample sent to the DAC is less than > realtime. But we are not talking anymore about sound quality. thx the gui performance was night and day type stuff -- waiting 2 seconds for a folder to open instead of 30 seconds but i didnt have gui performance problems before -- just started one day who knows maybe i`ll switch i back sometime and see what happens oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
another system question : i use a pi A+ with 512 ram under the test tab in advanced power management it list the ram as 256 could this be a problem ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > there is a change i made recently that i would like your opinion on > i have the picore on one pi installation -- lms and squeeze on same pi > i had slow response performance from the LMS gui > i looked at the boot codes and swap to disc / card was disabled > i enabled that -- thinking it might benefit lms and i assumed squeeze > would still write to ram > after that LMS gui ran much better and i thought i noticed a sound > improvement > possible ? Im not the maintainer of picore but in general enabling swap is not going to speed up a system. It might be necessary to make it work, but by definition you enable ram to be swapped out and in which is a slower process that if you have everything in ram (see caveat below). Now, these are complex systems and I cant talk why the UI seems more responsive to you, there could have been many reasons like some other processes not running any more or some processes would be able to allocate more memory and that would be a better option to have system swap rather than developer-implemented handling of low memory / allocation failures. Now, squeezelite allocates buffers and if allocation fails, squeezelite will carp. It will not run with degraded performances, it will crash. The only case where you might have audio issues resulting of cpu overload is when the rate of sample sent to the DAC is less than realtime. But we are not talking anymore about sound quality. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
2 new log files 1= locked at 24bit --- produces sound 1=locked at 16bit produces no sound look very similar to me -- just that first buffer is smaller with the 16 which i think makes sense but 24 bit works 16 bit doesnt work /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpihifiberry -a 80:4:24:1: -p 45 -d output=info -f /var/log/pcp_squeezelite.log [20:26:55.915909] output_init_alsa:933 init output [20:26:55.916481] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 24 mmap: 1 [20:26:55.933240] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [20:26:55.970199] output_init_alsa:999 memory locked [20:26:55.970463] output_init_alsa:1005 glibc detected using mallopt [20:26:55.971762] output_thread:682 open output device: hw:CARD=sndrpihifiberry [20:26:55.971968] alsa_open:351 opening device at: 44100 [20:26:55.975293] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S24_LE sample rate: 44100 mmap: 1 [20:26:55.975713] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [20:26:56.025586] output_flush:445 flush output buffer [20:28:49.086917] output_flush:445 flush output buffer [20:28:49.397440] _output_frames:65 start buffer frames: 71424 [20:28:49.397656] _output_frames:153 track start sample rate: 44100 replay_gain: 0 [20:31:58.889989] output_close_alsa:1030 close output /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -p 45 -d output=info -f /var/log/pcp_squeezelite.log [20:32:00.866069] output_init_alsa:933 init output [20:32:00.866639] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [20:32:00.883348] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [20:32:00.920607] output_init_alsa:999 memory locked [20:32:00.920873] output_init_alsa:1005 glibc detected using mallopt [20:32:00.922112] output_thread:682 open output device: hw:CARD=sndrpihifiberry [20:32:00.922308] alsa_open:351 opening device at: 44100 [20:32:00.925605] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S16_LE sample rate: 44100 mmap: 1 [20:32:00.926021] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [20:32:00.974201] output_flush:445 flush output buffer [20:32:00.976886] output_flush:445 flush output buffer [20:32:27.932498] output_flush:445 flush output buffer [20:32:28.227368] _output_frames:65 start buffer frames: 56448 [20:32:28.227581] _output_frames:153 track start sample rate: 44100 replay_gain: 0 oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
there is a change i made recently that i would like your opinion on i have the picore on one pi installation -- lms and squeeze on same pi i had slow response performance from the LMS gui i looked at the boot codes and swap to disc / card was disabled i enabled that -- thinking it might benefit lms and i assumed squeeze would still write to ram after that LMS gui ran much better and i thought i noticed a sound improvement possible ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > I'm going to give you my honest "scientific" response. I have a > specialization in digital signal processing and information theory > (grade 12 + 5 years) and 25+ years experience in software development > and implementation. I'm not bragging or trying to use the "argument of > authority" because the world is full of people much more knowledgeable > and intelligent than me, I just want to point out that I take my > recommendation from a mathematical + theory + experience background. > > So, any scientific response always wants to keep and open mind because > it's a trial and error progress, but we have to think in term of > probability and plausibility. If you ask me can I be hit by a meteorite, > the answer is yes but it is *very* unlikely. If you ask me if the earth > is flat or if the world was created 6000 years ago, the answer is no, > period and here there no question of "opening my mind". If you ask me > can a chip sound different depending on how the data is sent, the answer > is very (very, very) likely no, unless there is something totally broken > in the design. > > And we always try to think about level of impact / importance / risk > factor. There are so many more important reasons with effect orders of > magnitude (10^n) more visible. Can CPU activity, network activity have > an influence? Yes. When we do RF designs where we look at insane level > of sensitivity (where we have 160dB of coupling loss for commercial > products, so receiving 10^-17 watts), yes you can be sure that the > memory bus layout to the main processor and every track can matter but > even there the progress of chipsets integration and noise immunity has > been amazing in the past 20+ years. When we do simple audio design, oh > well, again, it is very very unlikely that there is any impact, unless > again, the design is totally broken and that's going to blow up in your > face immediately and all the time. Changing the CPU activity is just > levels of magnitude less impactful, if any. > > I'm not interested in flame wars and discussion on "bits are not bits" > for the reason I described above, with, but because you candidly asked > I'm giving you my honest view. thank you i appreciate that i`m just going to make sure i have this running properly maybe these logs will make me more confident or something and my head will clear from any biases what about these buffer sizes ? lots of wild claims about those out there i dont think i hear much, if any, difference there for someone with a pcm chip that wants the process as clean as can be, not interested in volume control, equalizers, sox resampling -- any advice you can give me on these settings would be appreciated oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
slartibartfast wrote: > Have you any links to claims that padding 16 bit to 24 bit changes the > sound? > > Sent from my Pixel 3a using Tapatalk i was just looking for them --- i read them a couple years ago - after i thought i noticed differences. havent found any yet, but was just reading this in my search i also found many threads like this, both a couple years ago during my first shot at picore and recently after moving back https://audiophilestyle.com/forums/topic/26693-audible-differences-between-squeezelite-and-mpd/ i dont want to search for this stuff and it is not my intention to insult i am just wondering if there is something i can do to make squeeze more to my liking or find out if i am doing something wrong it is possible it sounds exactly like my rune set up and its all in my head. i no longer have 2 identical players so an A/B not possible at the moment oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > ok > > serious questions - not playing games > > are there differing opinions on this ? -- a couple years ago in a > previous software setup i experimented with i think an alsa setting > which i thought just padded right before sending to dac. i have no idea > what it was actually doing. with identical players in an A/B i thought > there were noticeable differences. i`m not sure of the whole process -- > what you are describing here could be completely different from what i > was doing. i try my hardest to not to be an audiofool - i give the > benefit of the doubt to the scientist, but many others have also claimed > audible differences with padding the bit length. the dac chips accept > data in a few different ways i remember reading ( Correct me if i am > wrong ) is it possible for a chip to sound different depending on how > the data is sent ? if a computer program ran a set of data through some > unnecessary processes, on purpose, but the data arrived at the dac > unchanged -- is it possible to have a different sound ? > > would you say squeeze has a distinct sound ? if so, what would you > attribute that too ? I'm going to give you my honest "scientific" response. I have a specialization in digital signal processing and information theory (grade 12 + 5 years) and 25+ years experience in software development and implementation. I'm not bragging or trying to use the "argument of authority" because the world is full of people much more knowledgeable and intelligent than me, I just want to point out that I take my recommendation from a mathematical + theory + experience background. So, any scientific response always wants to keep and open mind because it's a trial and error progress, but we have to think in term of probability and plausibility. If you ask me can I be hit by a meteorite, the answer is yes but it is *very* unlikely. If you ask me if the earth is flat or if the world was created 6000 years ago, the answer is no, period and here there no question of "opening my mind". If you ask me can a chip sound different depending on how the data is sent, the answer is very (very, very) likely no, unless there is something totally broken in the design. And we always try to think about level of impact / importance / risk factor. There are so many more important reasons with effect orders of magnitude (10^n) more visible. Can CPU activity, network activity have an influence? Yes. When we do RF designs where we look at insane level of sensitivity (where we have 160dB of coupling loss for commercial products, so receiving 10^-17 watts), yes you can be sure that the memory bus layout to the main processor and every track can matter but even there the progress of chipsets integration and noise immunity has been amazing in the past 20+ years. When we do simple audio design, oh well, again, it is very very unlikely that there is any impact, unless again, the design is totally broken and that's going to blow up in your face immediately and all the time. Changing the CPU activity is just levels of magnitude less impactful, if any. I'm not interested in flame wars and discussion on "bits are not bits" for the reason I described above, with, but because you candidly asked I'm giving you my honest view. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > ok > > serious questions - not playing games > > are there differing opinions on this ? -- a couple years ago in a > previous software setup i experimented with i think an alsa setting > which i thought just padded right before sending to dac. i have no idea > what it was actually doing. with identical players in an A/B i thought > there were noticeable differences. i`m not sure of the whole process -- > what you are describing here could be completely different from what i > was doing. i try my hardest to not to be an audiofool - i give the > benefit of the doubt to the scientist, but many others have also claimed > audible differences with padding the bit length. the dac chips accept > data in a few different ways i remember reading ( Correct me if i am > wrong ) is it possible for a chip to sound different depending on how > the data is sent ? if a computer program ran a set of data through some > unnecessary processes, on purpose, but the data arrived at the dac > unchanged -- is it possible to have a different sound ? > > would you say squeeze has a distinct sound ? if so, what would you > attribute that too ? Have you any links to claims that padding 16 bit to 24 bit changes the sound? Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
so i ran this generic 5102 again with the format locked at 16 bit --- still no sound -- but log appears different : /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -p 45 -d output=info -f /var/log/pcp_squeezelite.log [17:56:52.176958] output_init_alsa:933 init output [17:56:52.177525] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [17:56:52.194860] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [17:56:52.231846] output_init_alsa:999 memory locked [17:56:52.232108] output_init_alsa:1005 glibc detected using mallopt [17:56:52.233358] output_thread:682 open output device: hw:CARD=sndrpihifiberry [17:56:52.233665] alsa_open:351 opening device at: 44100 [17:56:52.236813] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S16_LE sample rate: 44100 mmap: 1 [17:56:52.237229] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [17:56:52.282637] output_flush:445 flush output buffer [17:56:52.286906] output_flush:445 flush output buffer [18:01:11.588147] output_flush:445 flush output buffer [18:01:11.899281] _output_frames:65 start buffer frames: 97920 [18:01:11.899503] _output_frames:153 track start sample rate: 44100 replay_gain: 0 also found the "logs" tab -- big progress today oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > As a result of decoding, flac returns 32 bits samples but tells you what > the length of samples is (see https://xiph.org/flac/format.html). So > when it returns this array of 32 bits samples, they are right justified > (i.e. if these are 8 bits samples, the first 24+1 bits from the left are > 0 for a positive integer and 1 for a negative as it's 2's complement). > If you look at what squeezelite does, we re-align these samples to the > left in the internal buffer and then they are sent to the DAC/mixer with > potentially re-alignement / truncation depending what the DAC supports. > In other words, these left-justified 32 bits buffers can be truncated to > 16 bits integers and then send to the DAC/mixer if it has been > configured to accept 16 bits. > > But again, padding does not matter. A DAC configured to receive 32 bits > and getting 16 bits data in a 32 bits word, left-justified and with 16 > trailing 0, will produce the same result as it if was configured to > receive 16 bits and would actually receive the same 16 bits samples as > before. ok serious questions - not playing games are there differing opinions on this ? -- a couple years ago in a previous software setup i experimented with i think an alsa setting which i thought just padded right before sending to dac. i have no idea what it was actually doing. with identical players in an A/B i thought there were noticeable differences. i`m not sure of the whole process -- what you are describing here could be completely different from what i was doing. i try my hardest to not to be an audiofool - i give the benefit of the doubt to the scientist, but many others have also claimed audible differences with padding the bit length. the dac chips accept data in a few different ways i remember reading ( Correct me if i am wrong ) is it possible for a chip to sound different depending on how the data is sent ? if a computer program ran a set of data through some unnecessary processes, on purpose, but the data arrived at the dac unchanged -- is it possible to have a different sound ? would you say squeeze has a distinct sound ? if so, what would you attribute that too ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > are you saying that with flac there is actually no padding going on ? > that 32 bit is how it streams in ( for lack of better description ) ? > > how does wav return samples ? > > how come i never see 16bit unless i force it ? As a result of decoding, flac returns 32 bits samples but tells you what the length of samples is (see https://xiph.org/flac/format.html). So when it returns this array of 32 bits samples, they are right justified (i.e. if these are 8 bits samples, he first 24+1 bits from the left are 0 for a positive integer and 1 for a negative as it's 2's complement). If you look at what squeezelite does, we re-align these samples to the left in the internal buffer and then they are sent to the DAC/mixer with potentially re-alignement / truncation depending what the DAC supports. In other words, these left-justified 32 bits buffers can be truncated to 16 bits integers and then send to the DAC/mixer if it has been configured to accept 16 bits. But again, padding does not matter. A DAC configured to receive 32 bits and getting 16 bits data in a 32 bits word, left-justified and with 16 trailing 0, will produce the same result as it if was configured to receive 16 bits and would actually receive the same 16 bits samples as before. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
ok slart and paul think i`m making some progress appreciate the help have to take about 30 min off -- have 10 cats and dogs to feed but will be back need to review last couple posts again but hopefully i will be able to play something then stop - check a log and see exactly what it sent to dac ? ssh seems easier -- is log like that available through ssh ? the diagnostic page is info overload also dont know if it matters but i`m probably the only person using a pi A+ -- could that be an issue ? my experiences dont line up with what i read from other people sox upsampling, for example, seems horrible to me oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > i have that done -- not sure what i`m supposed to be looking at > > also is it dynamic -- if i make changes it keeps updating ? You need to update it manually by clicking "show". This is my log. Code: /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=E30,DEV=0 -a 80:4::1: -d output=info -f /var/log/pcp_squeezelite.log -D 0:u32be -v [20:02:09.272640] output_init_alsa:933 init output [20:02:09.272860] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: any mmap: 1 [20:02:09.281713] output_init_common:432 supported rates: 768000 705600 384000 352800 192000 176400 96000 88200 48000 44100 [20:02:09.310762] output_init_alsa:999 memory locked [20:02:09.310902] output_init_alsa:1005 glibc detected using mallopt [20:02:09.311469] output_thread:682 open output device: hw:CARD=E30,DEV=0 [20:02:09.311536] alsa_open:351 opening device at: 44100 [20:02:09.312832] alsa_open:422 opened device hw:CARD=E30,DEV=0 using format: S32_LE sample rate: 44100 mmap: 1 [20:02:09.312971] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [20:02:09.319737] output_vis_init:162 opened visulizer shared memory as /squeezelite-b8:27:eb:5f:a3:35 [20:02:09.340482] output_flush:445 flush output buffer [20:02:09.340838] output_flush:445 flush output buffer [20:03:27.988780] output_flush:445 flush output buffer [20:03:38.864892] _output_frames:65 start buffer frames: 12288 [20:03:38.865020] _output_frames:153 track start sample rate: 44100 replay_gain: 48640 slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Stop the squeezelite instance running from within pCP. Press stop button on the “Main” page of the web interface. Then try again piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
paul- wrote: > Just enter this on your ssh sesstion > > > Code: > > > sudo /usr/local/bin/squeezelite -n "piCorePlayer" -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -d output=debug > > > sudo /usr/local/bin/squeezelite -n "piCorePlayer" -o hw:CARD=sndrpihif iberry -a 80:4:16:1: -d output=debug [15:22:55.789661] output_init_alsa:933 init output [15:22:55.792267] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [15:22:55.795118] output_init_common:360 outputbuf size: 3528000 [15:22:55.797674] output_init_common:384 idle timeout: 0 [15:22:55.818639] ALSA snd_pcm_hw_open:1715 open '/dev/snd/pcmC0D0p' failed (-16) [15:22:55.820616] test_open:281 playback open error: Device or resource busy [15:22:55.821764] output_init_common:401 unable to open output device: hw:CARD=sndrpihifiberry oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Just enter this on your ssh sesstion Code: sudo /usr/local/bin/squeezelite -n "piCorePlayer" -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -d output=debug piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
paul- wrote: > What is your full squeezelite commandline? You can see it if you expand > the "more>" tag at the bottom of the squeezelite page. > > If you are experimenting, the best thing is to run squeezelite from an > ssh session (Manually typing the commandline) Make sure to stop > squeezelite in the pCP interface first, as only one can be using the > hardware at the same time. > > Run squeezelite with "sudo" not sure i have the chops for this shut down squeeze in the picore gui connected via ssh found some command line documentation but nothing clear for the lay person oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
The Generic pCM5102a codec driver plays fine locked at 16 bit Code: tc@piRate:~$ sudo /usr/local/bin/squeezelite -n "piRateAudio" -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -v -d output=debug [13:58:52.964199] output_init_alsa:933 init output [13:58:52.966520] output_init_alsa:973 requested alsa_buffer: 80 alsa_period: 4 format: 16 mmap: 1 [13:58:52.970462] output_init_common:360 outputbuf size: 3528000 [13:58:52.974155] output_init_common:384 idle timeout: 0 [13:58:52.990370] output_init_common:432 supported rates: 192000 176400 96000 88200 48000 44100 32000 16000 8000 [13:58:53.028404] output_init_alsa:999 memory locked [13:58:53.030515] output_init_alsa:1005 glibc detected using mallopt [13:58:53.035372] output_thread:682 open output device: hw:CARD=sndrpihifiberry [13:58:53.035553] alsa_open:351 opening device at: 44100 [13:58:53.037863] alsa_open:422 opened device hw:CARD=sndrpihifiberry using format: S16_LE sample rate: 44100 mmap: 1 [13:58:53.038174] alsa_open:513 buffer: 80 period: 4 -> buffer size: 3528 period size: 882 [13:58:53.045032] output_init_alsa:1025 set output sched fifo rt: 45 [13:58:53.049131] output_vis_init:162 opened visulizer shared memory as /squeezelite-b8:27:eb:66:c8:ee [13:58:53.162577] set_volume:233 setting internal gain left: 20992 right: 20992 [13:58:53.163059] set_volume:233 setting internal gain left: 20992 right: 20992 [13:58:53.659033] _output_frames:65 start buffer frames: 7168 [13:58:53.659222] _output_frames:153 track start sample rate: 44100 replay_gain: 0 piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
slartibartfast wrote: > You can set logging in squeezelite settings. Choose output=info from the > drop down list then click "save". To view the log > Main page/Diagnostics/Logs > select squeezelite from the drop down list. > > Sent from my Pixel 3a using Tapatalk i have that done -- not sure what i`m supposed to be looking at also is it dynamic -- if i make changes it keeps updating ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
bpa wrote: > Your last two posts are minimal - don't understand, > > You need to get logging working. > If your command lines parameters are wrong - squeezelite may not show an > error, may not stop and you may not get sound. > > Logging will show where you are going wrong. > > PCP is being used by many people who are fussy with their audio - IIRC > this 16 bit issue has not come up so I suspect you are chasing an idea > but not actually a problem. > > I'm now going offline for most of the evening. > > Go back to basics, > 1. get audio from standard setup > 2. get squeezelite logging working (I think PCP has its own way to save > these logs) > 3. Understand what output devices can provide audio and get plughw and > hw both working. > 4. Start experimenting with the "-a" command line with the "hw" device > and look at squeezelite log each with each test setting. thx for all the effort / info oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
You can set logging in squeezelite settings. Choose output=info from the drop down list then click "save". To view the log Main page/Diagnostics/Logs select squeezelite from the drop down list. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
/usr/local/bin/squeezelite -n "piCorePlayer" -o hw:CARD=sndrpihifiberry -a 80:4:16:1: -p 45 still wont play oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
thats what it is now --- playing let me go back to f=16 give me a few sec oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Your last two posts are minimal - don't understand, You need to get logging working. If your command lines parameters are wrong - squeezelite may not show an error, may not stop and you may not get sound. Logging will show where you are going wrong. PCP is being used by many people who are fussy with their audio - IIRC this 16 bit issue has not come up so I suspect you are chasing an idea but not actually a problem. I'm now going offline for most of the evening. Go back to basics, 1. get audio from standard setup 2. get squeezelite logging working (I think PCP has its own way to save these logs) 3. Understand what output devices can provide audio and get plughw and hw both working. 4. Start experimenting with the "-a" command line with the "hw" device and look at squeezelite log each with each test setting. 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
What is your full squeezelite commandline? You can see it if you expand the "more>" tag at the bottom of the squeezelite page. If you are experimenting, the best thing is to run squeezelite from an ssh session (Manually typing the commandline) Make sure to stop squeezelite in the pCP interface first, as only one can be using the hardware at the same time. Run squeezelite with "sudo" piCorePlayer a small player for the Raspberry Pi in RAM. Homepage: https://www.picoreplayer.org Please 'donate' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=U7JHY5WYHCNRU&lc=GB¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) if you like the piCorePlayer paul-'s Profile: http://forums.slimdevices.com/member.php?userid=58858 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
yep with the generic 5102 and 16 in that f field = no sound happened with rune also oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
the dac doesnt support 24 or hw in general doesnt support 24 ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > well after your last comment about cat not really showing you what is > going on -- i`m not sure > but > ALSA f =16 This doesn;t seem right. I'd expect forcing a format is done from the squeezelite command line using the "-a" - the alternative might be changing the alsa configuration for the device (or creating a new ALSA device with 16 bit limitation) 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
i will reboot into generic 5102 and see what happens oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Example of trying to force 24 input on a DAC using "hw" which does not support 24 Squeezelite can't open the device each time it tries, but it keep trying and doesn't stop - no indication of error. Logging is necessary. Code: $ ./alsacap -d hw:system,0 *** Exploring configuration space of device `hw:system,0' for playback *** 1..2 channels Sampling rate 6400..48000 Hz Sample formats: S16_LE Significant bits: 16 $ ./squeezelite -a ::24: -d all=info -o hw:system,0 [18:09:08.817367] stream_init:454 init stream [18:09:08.821199] output_init_alsa:933 init output [18:09:08.821220] output_init_alsa:973 requested alsa_buffer: 40 alsa_period: 4 format: 24 mmap: 1 [18:09:08.824210] output_init_common:432 supported rates: 48000 44100 32000 24000 22500 16000 12000 11025 8000 [18:09:08.826790] output_init_alsa:999 memory locked [18:09:08.826802] output_init_alsa:1005 glibc detected using mallopt [18:09:08.826870] decode_init:153 init decode [18:09:08.826885] output_thread:682 open output device: hw:system,0 [18:09:08.826917] alsa_open:351 opening device at: 44100 [18:09:08.826917] register_dsd:908 using dsd to decode dsf,dff [18:09:08.826933] register_alac:549 using alac to decode alc [18:09:08.826941] register_faad:663 using faad to decode aac [18:09:08.826946] register_vorbis:385 using vorbis to decode ogg [18:09:08.826951] register_opus:329 using opus to decode ops [18:09:08.826957] register_flac:332 using flac to decode ogf,flc [18:09:08.826963] register_pcm:483 using pcm to decode aif,pcm [18:09:08.826968] register_mad:423 using mad to decode mp3 [18:09:08.827043] discover_server:795 sending discovery [18:09:08.827184] discover_server:806 got response from: 192.168.0.127:3483 [18:09:08.827957] alsa_open:427 unable to open audio device requested format: S24_LE [18:09:08.827986] slimproto:898 connecting to 192.168.0.127:3483 [18:09:08.828044] slimproto:937 connected [18:09:08.828054] slimproto:948 local player [18:09:08.828058] sendHELO:148 mac: 74:da:38:a6:39:77 [18:09:08.828063] sendHELO:150 cap: CanHTTPS=1,Model=squeezelite,AccuratePlayPoints=1,HasDigitalOut=1,HasPolarityInversion=1,Balance=1,Firmware=v1.9.9-1386,ModelName=SqueezeLite,MaxSampleRate=48000,dsf,dff,alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3,loc [18:09:08.828594] decode_flush:236 decode flush [18:09:08.828604] output_flush:445 flush output buffer [18:09:13.828086] output_thread:682 open output device: hw:system,0 [18:09:13.828273] alsa_open:351 opening device at: 44100 [18:09:13.831816] alsa_open:427 unable to open audio device requested format: S24_LE [18:09:18.831975] output_thread:682 open output device: hw:system,0 [18:09:18.832169] alsa_open:351 opening device at: 44100 [18:09:18.835703] alsa_open:427 unable to open audio device requested format: S24_LE [18:09:22.738994] slimproto_stop:977 slimproto stop [18:09:22.839230] decode_close:221 close decode [18:09:22.843213] stream_close:508 close stream [18:09:22.937246] output_close_alsa:1030 close output 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
bpa wrote: > How are you forcing 16 bit ? well after your last comment about cat not really showing you what is going on -- i`m not sure but ALSA f =16 oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > but the 5102 drivers for the various pi dacs never work for me on any > software i have tried when i try to force 16bit -- no sound How are you forcing 16 bit ? 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
but the 5102 drivers for the various pi dacs never work for me on any software i have tried when i try to force 16bit -- no sound oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
i dont think that 5102 does 16 bit oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
pcp oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > "Interesting next log - as it show something I didn't expect. > Same device, similar test (2nd stream is 44.1Khz) only this time using > the "hw" - device is opened with S16_LE but re-oppend with S32_LE later. > I'm not sure why squeezelite has changed device but shows you need to > enable lgging to knwo what is going on." > > what are the implications of this ? I found out Pulseaudio was holding "native" driver and when I stopped and got access to Audio,0 - things were more expected. AFAIK - underlying chip is a 5102 also. Interesting this time sample size format S24_3LE. Repeat of 1st test - squeezelite opens at 44.1Khz (default value) but when I play a 48Khz - it reopens at 48Khz. Code: $ ./alsacap -d hw:Audio,0 *** Exploring configuration space of device `hw:Audio,0' for playback *** 2 channels Sampling rate 32000..96000 Hz Sample formats: S16_LE, S24_3LE $ ./squeezelite -o hw:Audio,0 -d output=info [17:32:29.074970] output_init_alsa:933 init output [17:32:29.075029] output_init_alsa:973 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1 [17:32:29.078434] output_init_common:432 supported rates: 96000 48000 44100 32000 [17:32:29.081343] output_init_alsa:999 memory locked [17:32:29.081358] output_init_alsa:1005 glibc detected using mallopt [17:32:29.081460] output_thread:682 open output device: hw:Audio,0 [17:32:29.081499] alsa_open:351 opening device at: 44100 [17:32:29.082657] alsa_open:422 opened device hw:Audio,0 using format: S24_3LE sample rate: 44100 mmap: 1 [17:32:29.082686] alsa_open:513 buffer: 40 period: 4 -> buffer size: 1764 period size: 441 [17:32:29.086060] output_flush:445 flush output buffer [17:34:41.484509] output_flush:445 flush output buffer [17:34:42.817065] _output_frames:65 start buffer frames: 12288 [17:34:42.817150] _output_frames:153 track start sample rate: 48000 replay_gain: 0 [17:34:42.827251] output_thread:682 open output device: hw:Audio,0 [17:34:42.827827] alsa_open:351 opening device at: 48000 ][17:34:42.828729] alsa_open:422 opened device hw:Audio,0 using format: S24_3LE sample rate: 48000 mmap: 1 [17:34:42.828749] alsa_open:513 buffer: 40 period: 4 -> buffer size: 1920 period size: 480 [17:34:48.474701] output_flush:445 flush output buffer oshcar wrote: > i can never get this logging to work > i will put some effort into it today > thx for this > i will look through it and see if i can get these logs working Get logs working or you'll never be certain what's is going on. What OS are you using ? PCP, Ubuntu, raspbian, ??? 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
"Interesting next log - as it show something I didn't expect. Same device, similar test (2nd stream is 44.1Khz) only this time using the "hw" - device is opened with S16_LE but re-oppend with S32_LE later. I'm not sure why squeezelite has changed device but shows you need to enable lgging to knwo what is going on." what are the implications of this ? i can never get this logging to work i will put some effort into it today thx for this i will look through it and see if i can get these logs working oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > ok bpa > > "Give specific exaplanations of the test "i never get 16bit output > unless i force with f=16 ( Rpi driver ) " so thatit can be understood." > > just booted up with Rpi driver -- hw:sendrpi output setting > > everything else default > > ALSA setting 80 4 _ 1 _ > > dont know if this qualifies as a test or not -- just playing a redbook > cd flac file > > cat /proc/asound/card0/pcm0p/sub0/hw_params > access: MMAP_INTERLEAVED > format: S24_LE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 882 > buffer_size: 3528 > > maybe ALSA is set to send highest format dac handle ? "cat" is not really a test. I think this is showing the defautl value. Use the logging value " -d output=info" and when squeezelite opens/reopens the output device, you'll see actual values. test below using a DAC called "Audio" - alscap shows different capabilities between "plughw" and "hw" Code: $ ./alsacap -d plughw:Audio,1 *** Exploring configuration space of device `plughw:Audio,1' for playback *** 1..1 channels Sampling rate 4000..4294967295 Hz Sample formats: S8, U8, S16_LE, S16_BE, U16_LE, U16_BE, S24_LE, S24_BE, U24_LE, U24_BE, S32_LE, S32_BE, U32_LE, U32_BE, FLOAT_LE, FLOAT_BE, FLOAT64_LE, FLOAT64_BE, MU_LAW, A_LAW, IMA_ADPCM, S20_LE, S20_BE, U20_LE, U20_BE, S24_3LE, S24_3BE, U24_3LE, U24_3BE, S20_3LE, S20_3BE, U20_3LE, U20_3BE, S18_3LE, S18_3BE, U18_3LE, U18_3BE $ ./alsacap -d hw:Audio,1 *** Exploring configuration space of device `hw:Audio,1' for playback *** 2 channels Sampling rate 48000 Hz Sample formats: S16_LE Significant bits: 16 For example, the ALSA device is opened with 44.1kHz when with nothing playing. When I started to play a 48Khz stream - it re-opens with 48Khz setting. The input stream is a 16bit 2 chan - so Squeezelite has opend DAC with S32LE by padding out with zeroes as "plughw" supports it Code: ./squeezelite -o plughw:Audio,1 -d output=info 16:58:12.376066] output_init_alsa:933 init output [16:58:12.376125] output_init_alsa:973 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1 [16:58:12.380868] output_init_common:432 supported rates: 768000 705600 384000 352800 192000 176400 96000 88200 48000 44100 32000 24000 22500 16000 12000 11025 8000 [16:58:12.384153] output_init_alsa:999 memory locked [16:58:12.384168] output_init_alsa:1005 glibc detected using mallopt [16:58:12.384277] output_thread:682 open output device: plughw:Audio,1 [16:58:12.384320] alsa_open:351 opening device at: 44100 [16:58:12.385562] alsa_open:422 opened device plughw:Audio,1 using format: S32_LE sample rate: 44100 mmap: 1 [16:58:12.385630] alsa_open:513 buffer: 40 period: 4 -> buffer size: 1764 period size: 441 [16:58:12.387386] output_flush:445 flush output buffer [16:58:53.032739] output_flush:445 flush output buffer [16:58:54.235678] _output_frames:65 start buffer frames: 45056 [16:58:54.235731] _output_frames:153 track start sample rate: 48000 replay_gain: 0 [16:58:54.245809] output_thread:682 open output device: plughw:Audio,1 [16:58:54.246511] alsa_open:351 opening device at: 48000 [16:58:54.247705] alsa_open:422 opened device plughw:Audio,1 using format: S32_LE sample rate: 48000 mmap: 1 [16:58:54.247773] alsa_open:513 buffer: 40 period: 4 -> buffer size: 1920 period size: 480 [16:59:02.475188] output_flush:445 flush output buffer Interesting next log - as it show something I didn't expect. Same device, similar test (2nd stream is 44.1Khz) only this time using the "hw" - device is opened with S16_LE but re-oppend with S32_LE later. I'm not sure why squeezelite has changed device but shows you need to enable lgging to knwo what is going on. Code: ./squeezelite -o hw:Audio,1 -d output=info [17:08:40.205122] output_init_alsa:933 init output [17:08:40.205170] output_init_alsa:973 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1 [17:08:40.207744] output_init_common:432 supported rates: 48000 [17:08:40.209907] output_init_alsa:999 memory locked [17:08:40.209918] output_init_alsa:1005 glibc detected using mallopt [17:08:40.210011] output_thread:682 open output device: hw:Audio,1 [17:08:40.210045] alsa_open:351 opening device at: 48000 [17:08:40.211020] alsa_open:422 opened device hw:Audio,1 using format: S16_LE sample rate: 48000 mmap: 1 [17:08:40.211041] alsa_open:513 buffer: 40 period: 4 -> buffer size: 1920 period size: 480 [17:08:40.216404] output_flush:445 flush output buffer [17:09:20.976643] output_flush:445 flush output buffer [17:09:22.761033] _output_frames:65 start buffer frames: 69743 [17:09:22.761118] _output_frames:153 track start sample rate: 44100 replay_gain: 0 [17:09:22.771192] output_thread:682 open output device: hw:Audio,1 [17:09:22.777322] alsa_open:351 opening device at: 44100 [17:09:22.7782
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
the Rpi driver i am pretty sure was made for a board that used pcm1794 which accepts 16 and 24 bit oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
i previously used rune but no deezer so here i am pretty sure those came through as 16bit i am well a where of tricks of the mind -- and have been fooled many times revealed during an A/B bit padding was not one of them oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
wav file 16bit source = same oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
ok bpa "Give specific exaplanations of the test "i never get 16bit output unless i force with f=16 ( Rpi driver ) " so thatit can be understood." just booted up with Rpi driver -- hw:sendrpi output setting everything else default ALSA setting 80 4 _ 1 _ dont know if this qualifies as a test or not -- just playing a redbook cd flac file cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 882 buffer_size: 3528 maybe ALSA is set to send highest format dac handle ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > but the dac accepts 24bit so no LSB -- those extra zeroes are not > dropped -- doesnt matter ?There is no information in the 8 LSBs so it makes > no difference if they are dropped or not. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
slartibartfast wrote: > No since the padding bits are all zero. > > Sent from my Pixel 3a using Tapatalk but the dac accepts 24bit so no LSB -- those extra zeroes are not dropped -- doesnt matter ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > are you saying that with flac there is actually no padding going on ? > that 32 bit is how it streams in ( for lack of better description ) ? > > how does wav return samples ? > > how come i never see 16bit unless i force it ? could some post a simple chain of events with a redbook cd flac file running through squeeze, no sox, no software conversions. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > Padding 16 to 32 bits, if the source is 16 bits does not change dynamic. > > > Now, there is a real benefit to use 32 bits integers as the internal > representation when you chain calculations as you need a precision that > using 16 bits interim results loses. If you take flac as an example, it > always returns 32 bits samples. If youre want to store decoded flac in > 16 bits arrays, you need a truncation loop. > > In addition, using 24 bits is a real problem for cpu. Integers are 8, > 16, 32 or 64 bits but there is no such a thing as 24 bits representation > and trying to fake one can complicate implementation a real lot. Hence > we use 32 bits and truncate them to 24 bits at the very last stage. are you saying that with flac there is actually no padding going on ? that 32 bit is how it streams in ( for lack of better description ) ? how does wav return samples ? how come i never see 16bit unless i force it ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > does padding 16 bit to 24 bit if source is 16 bit change dynamic range ?No > since the padding bits are all zero. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > Padding 16 to 32 bits, if the source is 16 bits does not change dynamic. > > > Now, there is a real benefit to use 32 bits integers as the internal > representation when you chain calculations as you need a precision that > using 16 bits interim results loses. If you take flac as an example, it > always returns 32 bits samples. If youre want to store decoded flac in > 16 bits arrays, you need a truncation loop. > > In addition, using 24 bits is a real problem for cpu. Integers are 8, > 16, 32 or 64 bits but there is no such a thing as 24 bits representation > and trying to fake one can complicate implementation a real lot. Hence > we use 32 bits and truncate them to 24 bits at the very last stage. does padding 16 bit to 24 bit if source is 16 bit change dynamic range ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > thankyou for this response. there is alot of good information here. i am > still processing it. will respond again. ok yes -- i want to avoid degradation i understand the LSB 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 ? even if i set ALSA f at 16 to drop the LSB later on before sending to dac -- what do i do if playing a 24/96 file ? -- then i have to manually change f to 24 every time ? 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 ? i have no desire to use sox 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 ? 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 Also -- if i pad a 16bit input to 24bit and send that to a dac that accepts 24bit -- have i increased the dynamic range ? oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
bpa wrote: > My point is, I think you want to avoid degradation rather than actively > "improve quality" > > > > > LSB = Least Significant Bits > > To convert a 16 bit auidio sample to a 24 bit audio sample you add 8 > zeroes od least significant bits. > > It is the similar as converting Euros to Cents - it is the same value > 1 = 100 cents - 2 least significant digist have been added - no change > in value. > > > > 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. > > Use ALSA "hw" devices and ALSA will not do any s/w conversions. > > ALSA is a general system which can handle many device capabiltiies so it > will do everything it can to avoid loss of quality in operations. This > means doing calculations/operations at highest resolution for as long as > possible and then dropping unusable bits when passed to hardware (e.g. > 32bit answer chopped to 16 bits to DAC). > > ALSA can do software conversion when required (e.g. input 24 bit sample > but DAC only support 16 bit), volume control (add bits, volume adjust > and then truncate as required), resample (e.g. 96Khz to 44.1Khz if DAC > only support 44.1Khz). ALSA devices can also have other abilities such > as snoop, mixers etc. > > SOX will do same job as ALSA because not all SB players have ALSA. SOX > is most often used to resample - in LMS user can have better control of > resampling algorithm than letting ALSA resample. Some users use SOX to > upsample. > > 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. thankyou for this response. there is alot of good information here. i am still processing it. will respond again. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > does padding with zeroes increase dynamic range ? > > 16 bit to 32 bit to 24 bit > > doesnt 16bit to 24bit seem cleaner ? -- does it matter -- i dont know -- > i just want to try it to see if it makes a difference to my ears. or > maybe just knowing that one step is removed will make it sound better to > me. who cares. it will sound better to me. > > Changing a "32" to a "24" somewhere in the code cant be that difficult > correct ? -- if it crashes on me then it crashes. no big deal. Padding 16 to 32 bits, if the source is 16 bits does not change dynamic. Now, there is a real benefit to use 32 bits integers as the internal representation when you chain calculations as you need a precision that using 16 bits interim results loses. If you take flac as an example, it always returns 32 bits samples. If youre want to store decoded flac in 16 bits arrays, you need a truncation loop. In addition, using 24 bits is a real problem for cpu. Integers are 8, 16, 32 or 64 bits but there is no such a thing as 24 bits representation and trying to fake one can complicate implementation a real lot. Hence we use 32 bits and truncate them to 24 bits at the very last stage. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > does padding with zeroes increase dynamic range ? > > 16 bit to 32 bit to 24 bit > > doesnt 16bit to 24bit seem cleaner ? -- does it matter -- i dont know -- > i just want to try it to see if it makes a difference to my ears. or > maybe just knowing that one step is removed will make it sound better to > me. who cares. it will sound better to me. > > Changing a "32" to a "24" somewhere in the code cant be that difficult > correct ? -- if it crashes on me then it crashes. no big deal. btw -- your response = "purley to save memory and cpu" -- i like that too -- dont see how that could ever be a negative thing oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
philippe_44 wrote: > Squeezelites internal representation of samples is always 32 bits. Ive > done a 16 bits version for the esp32 implementation but its purely to > save memory and cpu. > > Without questioning that you hear a difference, I can ensure you that > padding 0s is not the cause, you should investigate other reasons. does padding with zeroes increase dynamic range ? 16 bit to 32 bit to 24 bit doesnt 16bit to 24bit seem cleaner ? -- does it matter -- i dont know -- i just want to try it to see if it makes a difference to my ears. or maybe just knowing that one step is removed will make it sound better to me. who cares. it will sound better to me. Changing a "32" to a "24" somewhere in the code cant be that difficult correct ? -- if it crashes on me then it crashes. no big deal. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > "improve sound quality" -- i have no desire to argue this. My potion Is I think you want avoid degradation rather than actively "improve signal" > dont know what LSB is LSB = Least Significant Bits To convert a 16 bit auidio sample to a 24 bit audio sample you add 8 zeroes od least significant bits. It is the similar as converting Euros to Cents - it is the same value €1 = 100 cents - 2 least significant digist have been added - no change in value. > dac chip accepts 16 bit -- dont why it needs more zeroes, or why it > needs 16 more zeroes instead of 8 more zeroes. 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. Use ALSA "hw" devices and ALSA will not do any s/w conversions. ALSA is a general system which can handle many device capabiltiies so it will do everything it can to avoid loss of quality in operations. This means doing calculations/operations at highest resolution for as long as possible and then dropping unusable bits when passed to hardware (e.g. 32bit answer chopped to 16 bits to DAC). ALSA can do software conversion when required (e.g. input 24 bit sample but DAC only support 16 bit), volume control (add bits, volume adjust and then truncate as required), resample (e.g. 96Khz to 44.1Khz if DAC only support 44.1Khz). ALSA devices can also have other abilities such as snoop, mixers etc. SOX will do same job as ALSA because not all SB players have ALSA. SOX is most often used to resample - in LMS user can have better control of resampling algorithm than letting ALSA resample. Some users use SOX to upsample. So if have 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. 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > "improve sound quality" -- i have no desire to argue this. > dont know what LSB is > dac chip accepts 16 bit -- dont why it needs more zeroes, or why it > needs 16 more zeroes instead of 8 more zeroes. Squeezelites internal representation of samples is always 32 bits. Ive done a 16 bits version for the esp32 implementation but its purely to save memory and cpu. Without questioning that you hear a difference, I can ensure you that padding 0s is not the cause, you should investigate other reasons. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
bpa wrote: > I think you need to be be more specific again about "improve sound > quality". > > It feels like you are concerned that somehow padding is degrading the > original audio samples - it is not, it is adding zeroes to the LSB which > are needed if the destination or a calculation requires it. "improve sound quality" -- i have no desire to argue this. dont know what LSB is dac chip accepts 16 bit -- dont why it needs more zeroes, or why it needs 16 more zeroes instead of 8 more zeroes. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > I am just trying to improve sound quality. something about picore sound > has never sat right with me. i have played around with the bit length > padding alot in other software and have never liked padding 16bit source > material to 32 bit. when i suspected that picore was padding everything > to 32 bit it just made me feel this was possibly the reason i am > uncomfortable with the sound. 24bit i can live with in other software, > so i would just like to try this. i dont like SOX up-sampling so i like > to avoid it if possible. i know some people will say the bit padding is > inaudible but i have A/B`d it with identical players, so . > as far as ALSA goes, i just want the most generic setup possible - no > software conversion desired. currently i am using the generic 5102 with > the "output setting" cleared to blamk. I think you need to be be more specific again about "improve sound quality". It feels like you are concerned that somehow padding is degrading the original audio samples - it is not, it is adding zeroes to the LSB which are needed if the destination or a calculation requires it. 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
also my dac chip, pcm1793, states in documentation that it accepts up to 24bit, doesnt specify 32bit but in practice it does accept 32bit. so who knows what is going on internally there. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
in addition to the als setup from previous post -- i also set f to 24 for the generic 5102 so 16bit to 32bit to 24bit seems unnecessary oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
bpa wrote: > If you could explain what problem you are trying to solve and give a > specific example (including input file format, h/w and ALSA devices > being used), it might help getting more explicit answers. > > ALSA is an interface to devices. It has capability to software convert > "input" and device capabilities using "plughw" devices or not to do > software conversion using the equivalent "hw" devices. I am just trying to improve sound quality. something about picore sound has never sat right with me. i have played around with the bit length padding alot in other software and have never liked padding 16bit source material to 32 bit. when i suspected that picore was padding everything to 32 bit it just made me feel this was possibly the reason i am uncomfortable with the sound. 24bit i can live with in other software, so i would just like to try this. i dont like SOX up-sampling so i like to avoid it if possible. i know some people will say the bit padding is inaudible but i have A/B`d it with identical players, so . as far as ALSA goes, i just want the most generic setup possible - no software conversion desired. currently i am using the generic 5102 with the "output setting" cleared to blamk. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
oshcar wrote: > thx Greg > > at the very least it should be possible to go into the relevant piece of > code and change a "32" to "24", so the software runs the same only with > 24bit length instead of 32. > I understand this may complicate SOX implementation -- for example : > 28bit precision -- but that doesnt seem necessary if you dont up-sample > or just want to up-sample 16bit source material. If you could explain what problem you are trying to solve and give a specific example (including input file format, h/w and ALSA devices being used), it might help getting more explicit answers. ALSA is an interface to devices. It has capability to software convert "input" and device capabilities using "plughw" devices or not to do software conversion using the equivalent "hw" devices. 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Greg Erskine wrote: > Welcome :) thx Greg at the very least it should be possible to go into the relevant piece of code and change a "32" to "24", so the software runs the same only with 24bit length instead of 32. I understand this may complicate SOX implementation -- for example : 28bit precision -- but that doesnt seem necessary if you dont up-sample or just want to up-sample 16bit source material. oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
Welcome :) Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
[SlimDevices: Plugins] Picore - Squeezelite 32 bit length padding
hello I have a couple questions if someone more knowledgeable could help : regarding ALSA settings - sample format (f) --- is there a value so that the ALSA output is the same as the source input -- for example 16bit input = 16bit output and 24bit input = 24bit output without having to manually change format settings ? maybe related i read in some documentation that when using SOX, picore hands of the data to sox internally as 32bit --- does this mean that all source inputs to picore are padded up to 32bit internally, regardless whether using sox or not, and passed of to ALSA as 32bit ? if this is the case, can this be tweaked easily ? maybe inject some code through SSH to either use either source format, 24bit, or 32 bit ? then the same type of command for ALSA format --- use whatever format being passed to it ? Report Post oshcar's Profile: http://forums.slimdevices.com/member.php?userid=71999 View this thread: http://forums.slimdevices.com/showthread.php?t=114947 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
