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
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
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
>
>
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
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
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
>
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,
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.
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
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:
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. +
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. +
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
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
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.
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
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'
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
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:
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
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:
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 --
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
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
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
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
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
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
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
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
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
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
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
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'
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
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:
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
>
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]
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
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
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
/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:
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
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
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
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:
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
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
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
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
***
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:
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:
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:
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
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
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
"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
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 _
>
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:
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
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
___
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
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 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:
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
>
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
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
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
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
85 matches
Mail list logo
