There is no bug! S24_LE is supported, S24_3LE is not.
There are so many advanced programmers around, it should be a piece of cake to straighten out the issue. Even I got very close to get it done.
No, you did not get close! (And you sure as hell don't know why you didn't get close! I hope we are talking about the same thing.... What you said before about changing all instances of S24_LE in the code to S24_3LE..... Seriously, Florien told you that would work?)
I'm not declaring aplay as a "nonsense tool". I asked if that is what you are actually using to listen to music. I expected you to say that you are using mpd or squeezelite or something like that..... ie. something that does support S24_LE and can convert/pad 3 byte 24 bit, to 4 byte 24 bit.
The drivers conform to ALSA. They are not broken. Nothing is broken. There is no conspiracy. S24_3LE is not supported directly by the driver. It's really simple!
You're wrong. Period.
Alsa clearly defines what S24_LE and S24_3LE is.
S24_LE is defined differently - as 3 byte format and S24_3LE is not defined at all in the drivers.
If that's not a bug, I don't know what else can be called bug.
And yes. Florian told me exactly what I said. I even sent him my patch.
Alsa clearly defines what S24_LE and S24_3LE is.
S24_LE is defined differently - as 3 byte format and S24_3LE is not defined at all in the drivers.
If that's not a bug, I don't know what else can be called bug.
And yes. Florian told me exactly what I said. I even sent him my patch.
I have no interest in arguing with you......
OK. It's a bug. Because the driver doesn't support S24_3LE, (which it never ever claimed to do, in the first place), it's buggy!
Well, on that point I am really surprised. Out of respect for Florian, I won't comment further.
Yes, it does!
Really, who told you that? S24_LE is a 4 byte format! Only 3 of the bytes are used for payload. (24 bits of data stored in a 32 bit word.)
EDIT: 20160216 1809
Code:
SND_PCM_FORMAT_S24_LE
Signed 24 bit Little Endian using low three bytes in 32-bit word
Last edited:
Greetings to all,
Although I ended up reading this thread while documenting on these small "myracle" DACs to add one to my new RPi 2, may I say that it is one of the most interesting discussions on the subject, even for a neophite like me (but I do try to read between the lines).
Maybe this post of diyinhk could be of some help here?: http://www.diyaudio.com/forums/digi...eam-verify-real-bit-perfect-oscilloscope.html
Talking about comparative devices, I saw that a 3-rd version of the Audiophonics I-Sabre ES9023 DAC (V3) was recently launched on their website, sporting some new "advanced power management (type ATX)" functions together with a dedicated (and mandatory) power connection (although it can power the Pi also). What would you guys think of it on a first glance?
Thank you and good luck to soundcheck and the other active contributors to this thread.
Cheers!
Although I ended up reading this thread while documenting on these small "myracle" DACs to add one to my new RPi 2, may I say that it is one of the most interesting discussions on the subject, even for a neophite like me (but I do try to read between the lines).
Maybe this post of diyinhk could be of some help here?: http://www.diyaudio.com/forums/digi...eam-verify-real-bit-perfect-oscilloscope.html
Talking about comparative devices, I saw that a 3-rd version of the Audiophonics I-Sabre ES9023 DAC (V3) was recently launched on their website, sporting some new "advanced power management (type ATX)" functions together with a dedicated (and mandatory) power connection (although it can power the Pi also). What would you guys think of it on a first glance?
Thank you and good luck to soundcheck and the other active contributors to this thread.
Cheers!
guys,
it is always good to have a better resolution if your system supports it (CPU and DAC) in case of digital volume:
let's take an example:
imagine a 24 bits sample.
You want to set the volume at 50%
It means divide the sample by 2.
=> You lost 1 bits / 24 it means you may lost 4% data quality (1/24) if the sample value is not multiple of 2.
Now, let's imagine you upgrade the 24 bits sample to a 32 bits sample:
it means x 256.
At this stage, no losts, because an integer x 256 is always an integer.
I want to set my volume at 50%
It means divide the sample value by 2.
Integer x 256 / 2 is like Integer x 128
=> No data losts.
And What is funny, is to imagine volume control on PC and volume control on DAC.
imagine after setting the volume at 50% on a PC you set it to 200% on a DAC....
no data losts at 32 bits. data losts at 24 bits (for this example)
it is always good to have a better resolution if your system supports it (CPU and DAC) in case of digital volume:
let's take an example:
imagine a 24 bits sample.
You want to set the volume at 50%
It means divide the sample by 2.
=> You lost 1 bits / 24 it means you may lost 4% data quality (1/24) if the sample value is not multiple of 2.
Now, let's imagine you upgrade the 24 bits sample to a 32 bits sample:
it means x 256.
At this stage, no losts, because an integer x 256 is always an integer.
I want to set my volume at 50%
It means divide the sample value by 2.
Integer x 256 / 2 is like Integer x 128
=> No data losts.
And What is funny, is to imagine volume control on PC and volume control on DAC.
imagine after setting the volume at 50% on a PC you set it to 200% on a DAC....
no data losts at 32 bits. data losts at 24 bits (for this example)
Last edited:
Today I was thinking how to generate a S24_LE 4-byte audio stream. sox just builds
standard S24_3LE as 24bit format.
speaker-test - the Alsa test-utility - that might be it!??!
(speaker-test is part of the alsa-utils package. If you have aplay, alsamixer installed you'll also have speaker-test on the system. )
Below examples generate nice 440Hz sine test-tones switching from left to right channel.
@0db = 100% level though. Don't run this without any volume control in the path. You might kill your speakers.
16 and 32 bit work fine.
standard S24_3LE as 24bit format.
speaker-test - the Alsa test-utility - that might be it!??!
(speaker-test is part of the alsa-utils package. If you have aplay, alsamixer installed you'll also have speaker-test on the system. )
Below examples generate nice 440Hz sine test-tones switching from left to right channel.
@0db = 100% level though. Don't run this without any volume control in the path. You might kill your speakers.
Code:
root@alpha ~ # speaker-test -D hw:0,0 -c 2 --rate 48000 --format S24_LE -f 440 -t sine
speaker-test 1.1.0
Format S24_LE is not supported...
root@alpha ~ # speaker-test -D hw:0,0 -c 2 --rate 48000 --format S24_3LE -f 440 -t sine
speaker-test 1.1.0
Format S24_3LE is not supported...
root@alpha ~ # speaker-test -D hw:0,0 -c 2 --rate 48000 --format S32_LE -f 440 -t sine
speaker-test 1.1.0
Playback device is hw:0,0
Stream parameters are 48000Hz, S32_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 8 to 65536
Period size range from 4 to 32768
Using max buffer size 65536
Periods = 4
was set period_size = 16384
was set buffer_size = 65536
0 - Front Left
1 - Front Right
Time per period = 4.142251
0 - Front Left
1 - Front Right
^CTime per period = 4.00834316 and 32 bit work fine.
Which might be explained by them being supported formats.....
Code:
$ speaker-test -h
.........
Recognized sample formats are: S8 S16_LE S16_BE FLOAT_LE S32_LE S32_BESoundcheck, are you using hifiberry_dac driver with your Mambo DAC? I've attached a patch for rpi-4.4.y. If you specify "dtoverlay=hifiberry-dac,bclk_ratio_integer_div" in your config text, you can decide if you can hear a difference between PLLD and OSC using bclk_ratio trick. You'll need to use 48k/96k (multiple of 8k and less than 192k) source material for comparison, anything else will result in continuing to use PLLD.
Code:
##
## dtoverlay=hifiberry-dac
##
** 48k/32bit (bclk_ratio=64) output using PLLD MASH **
hw_params: frequency=48000, sample_bits=32, physical_bits=32, bclk_ratio=64,
channels=2.
Setting bclk_ratio: 64
Using PLLD: clock_freq=500000000, target_freq=3072000, sampling_rate=48000,
bclk_ratio=64, divi=162, divf=3114
** 96k/32bit (bclk_ratio=64) output using PLLD MASH **
hw_params: frequency=96000, sample_bits=32, physical_bits=32, bclk_ratio=64,
channels=2.
Setting bclk_ratio: 64
Using PLLD: clock_freq=500000000, target_freq=6144000, sampling_rate=96000,
bclk_ratio=64, divi=81, divf=1557
##
## dtoverlay=hifiberry-dac,bclk_ratio_integer_div
##
** 48k/32bit (bclk_ratio=100) output using 19M2 OSC with integer divisor **
hw_params: frequency=48000, sample_bits=32, physical_bits=32, bclk_ratio=64,
channels=2.
Setting bclk_ratio: 100
Using OSC: clock_freq=19200000, target_freq=4800000, sampling_rate=48000,
bclk_ratio=100, divi=4, divf=0
** 96k/32bit (bclk_ratio=100) output using 19M2 OSC with integer divisor **
hw_params: frequency=96000, sample_bits=32, physical_bits=32, bclk_ratio=64,
channels=2.
Setting bclk_ratio: 100
Using OSC: clock_freq=19200000, target_freq=9600000, sampling_rate=96000,
bclk_ratio=100, divi=2, divf=0Yep. I'm using the HifiBerry-DAC driver for the MamboBerry.
Though. Last time I tried, I didn't make the MamboBerry work under 4.4. I've been using the 4.4. default_config.
That's why I'm still running 4.1.
Thx a lot for the patch anyhow. Great to see that you took that initiative.
Though. Last time I tried, I didn't make the MamboBerry work under 4.4. I've been using the 4.4. default_config.
That's why I'm still running 4.1.
Thx a lot for the patch anyhow. Great to see that you took that initiative.
Last edited:
Actually, this is just one feature that I have split out of a dedicated Pi/Sabre driver, and "bolted" into the berry_dac driver which I believe you will be using, in order that you could have it now, rather than have to wait until that dedicated driver gets up-streamed, which may never happen. (I didn't so much take the initiative, well, not to do any work anyway, just to split out what has already been done and give it to you in a usable, (for you), format. This code has been being used for over a year now, by others with a "player" product that is still not publicly released.)
Anyway, I tested with 2x other, different, off the shelf and publicly available Sabre boards this morning, using that code and the berry_dac driver, with squeezelite opening the output device at 16/24/32 bit. If it doesn't work with Mambo, I don't have one of those for testing myself. YMMV.
I managed to get it working. I guess my buffer settings were causing that strange behavior.
I havn't done any comparisons yet - tommorrow I'll do.
Just had a look at dmesg
I think that's normal since there is no pcm5102.
I havn't done any comparisons yet - tommorrow I'll do.
Just had a look at dmesg
Code:
4.552313] snd-hifiberry-dac sound: ASoC: CPU DAI (null) not registered
[ 4.553466] snd-hifiberry-dac sound: snd_soc_register_card() failed: -517
[ 4.559397] snd-hifiberry-dac sound: ASoC: CODEC DAI pcm5102a-hifi not registered
[ 4.561589] snd-hifiberry-dac sound: snd_soc_register_card() failed: -517I think that's normal since there is no pcm5102.
What does this mean? If up-sampled to 384, bypasses the filter because not needed, or do you need to supply an external filter?
Can you up-sample to 384 with squeezelite -R ? 384 prob needs added to the D+ Pro driver though.
BTW, you guys are crazy in the mods haha
We might as well break out KiCad and design a new board!
Missed this thread somehow, it's in an odd section.
What does this mean? If up-sampled to 384, bypasses the filter because not needed, or do you need to supply an external filter?
Can you up-sample to 384 with squeezelite -R ? 384 prob needs added to the D+ Pro driver though.
BTW, you guys are crazy in the mods haha
We might as well break out KiCad and design a new board!
Missed this thread somehow, it's in an odd section.
Scott,
Happy to have you here and joining the party. I just realized you are the same Scott Kramer from the HiFiBerry threads... YAY!
On filters, AFAIK, upsampling generally involves some sort of filter unless you do a specifically NOS one (and I'm not sure that you can actually do that while upsampling). So in most (maybe all) cases, you ARE doing a filter when upsampling... and on the PCM51xx chips, when you provide them with a 352/384 sample rate input, they don't use any on-board filtering at all.
Backstory on filtering... ALL digital playback involves filtering somewhere. Even NOS setups depend on the filtering already in your amps, speakers, and ears to roll-off the high-frequency digital nasties. Some DAC designers have delved into the filters imbedded in most modern digital chips and found they are not necessarily good sounding one, but largely chosen and tweaked to produce the best datasheet spec. Some designers have gone to computer-generated filtering (HQPlayer's DSC1, XXHigh-End's Phasoar DAC, the Lampizator DSD DACs & those similar) and others to FPGA-generated ones (PS Audio, Chord, Bottlehead). IF we can get 352/384 upsampling out of the lowly Pi, based on the experience of those who have the Bottlehead DAC (which uses the lowly PCM5142, a kissing cousin of the HFBD+P's PCM5122) we can unlock untold potential in that chip after we tweak the filtering of that upsampling.
One experience that cemented the importance of filtering in a DACs performance to me was that of those using the now a year-old Soekris DAM DAC, which has loadable filtering functionality. The device sounded ok with the stock filters and people reported significant SQ lifts with filters developed by the user community (my experience too!).
Enough on this... onto HW mods...
In my next post.
Greg in Mississippi
Last edited:
I made slow progress this week due to a pretty heavy work and social calendar... and this weekend due to some serious spring allergy junk. BUT I did make progress and am listening to my HFBD+P with the Pi, the DAC digital circuits and clocks, and the DAC output circuits all powered separately.
I power the Pi with a modified K&K auxiliary power supply with a larger xfrmr, more capacitance, and an LT3083 instead of 3080 for more current output.
The DAC halves are each powered through 1/2 of an OPC paralleled LT3042 regulator board (about 17,000uf on each board per rail) and supplied by two supplies on my digital source power board which start with separate secondaries on a transformer, with the one powering the DAC digital & clocks using a 30,000uf Mundorf and the one powering the DAC output using a 47,000uf Jensen 4-pole.
After updating it for this setup yesterday and this morning, I ran it first with a single 5v supply from the K&K setup, then split the DAC outputs from the DAC digital/clocks & Pi by removing the 0-ohm and adding the 2nd supply (and connecting the Pi-generated 3.3v to the DAC digital/clocks 3.3v rails) then disconnecting that link and adding the third supply.
I didn't have a lot of run-in time when I listened, so take these comments with a grain of salt... As I said earlier, the single supply with the mods I made to the board were better than the stock setup, but not necessarily better than the modified DVD player in that same system. Going to the 2-supply source was the biggest jump of the 4 different options I've tried (stock with 1x 5v, modified board with 1x 5v, mod'd with 2x 5v, mod'd with 2x 5v + 3.3v) and I suspect the biggest bang for the buck. I will revisit that at some point as I can go back to that by re-making two connections and just using two supplies.
The 2-supply setup made it roughly equivalent to the modified DVD player, with very little 'digitalitus; and good listenability.
Then I went to the 3-supply setup. The difference between it and the 2-supply setup was not nearly as large as that between the 2-supply and the 1-supply setup, but well worthwhile... refinement, sense of space and placement were all improved. And my first impression is that it now beats that DVD player.
Now to give it some burn-in time and listen again next weekend.
And I'll post some pix soon, likely tomorrow or the next day (when I feel a bit better).
Greg in Mississippi
I power the Pi with a modified K&K auxiliary power supply with a larger xfrmr, more capacitance, and an LT3083 instead of 3080 for more current output.
The DAC halves are each powered through 1/2 of an OPC paralleled LT3042 regulator board (about 17,000uf on each board per rail) and supplied by two supplies on my digital source power board which start with separate secondaries on a transformer, with the one powering the DAC digital & clocks using a 30,000uf Mundorf and the one powering the DAC output using a 47,000uf Jensen 4-pole.
After updating it for this setup yesterday and this morning, I ran it first with a single 5v supply from the K&K setup, then split the DAC outputs from the DAC digital/clocks & Pi by removing the 0-ohm and adding the 2nd supply (and connecting the Pi-generated 3.3v to the DAC digital/clocks 3.3v rails) then disconnecting that link and adding the third supply.
I didn't have a lot of run-in time when I listened, so take these comments with a grain of salt... As I said earlier, the single supply with the mods I made to the board were better than the stock setup, but not necessarily better than the modified DVD player in that same system. Going to the 2-supply source was the biggest jump of the 4 different options I've tried (stock with 1x 5v, modified board with 1x 5v, mod'd with 2x 5v, mod'd with 2x 5v + 3.3v) and I suspect the biggest bang for the buck. I will revisit that at some point as I can go back to that by re-making two connections and just using two supplies.
The 2-supply setup made it roughly equivalent to the modified DVD player, with very little 'digitalitus; and good listenability.
Then I went to the 3-supply setup. The difference between it and the 2-supply setup was not nearly as large as that between the 2-supply and the 1-supply setup, but well worthwhile... refinement, sense of space and placement were all improved. And my first impression is that it now beats that DVD player.
Now to give it some burn-in time and listen again next weekend.
And I'll post some pix soon, likely tomorrow or the next day (when I feel a bit better).
Greg in Mississippi
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.