@clivem
I have been sneaking around on the Archphile site.
I stepped over below changelog entry on his latest realease for the Pi:
Do you have an idea what that means???
Thx.
I have been sneaking around on the Archphile site.
I stepped over below changelog entry on his latest realease for the Pi:
Code:
– Custom patched 4.1.17 linux kernel that enables true 24 bit support using I2S connectivity and updated bclk_ratio valuesDo you have an idea what that means???
Thx.
Soundcheck,
Thanks for the reminder. I do have this on the list, but below the power feed experiments... and if I haven't gotten pretty darned good results after getting to three-power feeds, I'll probably give up at that time.
Still, the results from the weekend's work was promising.
Greg in Mississippi
Thanks for the reminder. I do have this on the list, but below the power feed experiments... and if I haven't gotten pretty darned good results after getting to three-power feeds, I'll probably give up at that time.
Still, the results from the weekend's work was promising.
Greg in Mississippi
Nope, not a clue. Need to see whatever patch they are using, that "supposedly" provides that functionality.
EDIT: I assume this is meant to be the patch, fix_24_bit_i2s.patch, but it doesn't seem to contain anything.
Last edited:
I should add that listening to the R-Pi->Soekris DAM DAC combo again last night, even without any mods including the must-do shift register supply mods, is setting a pretty darned high bar! I continued to be very impressed with it!
I am hopeful though that the 3-feed supply AND alternative filtering (if possible on the Pi) will bring the HFBD+P at least even or possibly slightly above every other digital source I have on hand at this time.
Greg in Mississippi
Sorry folks, if I mix up HW and SW talk.
But I think it's good to have it all in one thread.
Just for fun I looked up the PI I2S driver. When looking at the I2S driver code a comment hit my eyes.
Following up about it I found some interesting discussions of the designers.
And I also realized that it is not that simple to package all bits into frames towards the DAC.
After reading all that I had the impression - I might be wrong - that 48000/96000 are the preferred I2S samplerates, because we'd run in "Integer Mode" when running PI-I2S DACs.
With e.g. 44.1khz we'd run the Mash mode, causing higher jitter then Integer mode..
I wasn't aware of it until now.
Unfortunately 99% of all music is.... ....yep, 44.1khz.
All that seem to apply to the DACs, which are slaved to PI2 I2S, such as Mamboberry, iQaudio etc.. I don't know though, if that also applies to the DAC+ Pro. I don't think so!??!
Conclusion:
It seems that running Integer Mode leads to lower jitter.
If that's the case I'd say that resampling the data to e.g. 32bit/48khz might be really beneficial.
Again. I don't know if that applies to the DAC+ Pro, since it uses its own clocks for I2S.
The final question then would be for the DACs affected:
What's worse, the extra jitter due to Mash mode or the resampling associated losses?
We need to figure it out!
Cheers
PS: I guess the Archphile patch refers to the new 50/50/100 blck_ratio setting. Beside that they had 24bit support disabled due to XBMC issues.
But all that seems to be solved now. The changes seem to be included in my latest 4.1 kernel download from last weekend.
They still have that S24_3LE/S24_LE terminology problem in the driver! They are just not in line with Alsa.
But I think it's good to have it all in one thread.
Just for fun I looked up the PI I2S driver. When looking at the I2S driver code a comment hit my eyes.
Code:
/*
* Clock Settings
*
* The target frequency of the bit clock is
* sampling rate * frame length
*
* Integer mode:
* Sampling rates that are multiples of 8000 kHz
* can be driven by the oscillator of 19.2 MHz
* with an integer divider as long as the frame length
* is an integer divider of 19200000/8000=2400 as set up above.
* This is no longer possible if the sampling rate
* is too high (e.g. 192 kHz), because the oscillator is too slow.
*
* MASH mode:
* For all other sampling rates, it is not possible to
* have an integer divider. Approximate the clock
* with the MASH module that induces a slight frequency
* variance. To minimize that it is best to have the fastest
* clock here. That is PLLD with 500 MHz.
*/Following up about it I found some interesting discussions of the designers.
And I also realized that it is not that simple to package all bits into frames towards the DAC.
After reading all that I had the impression - I might be wrong - that 48000/96000 are the preferred I2S samplerates, because we'd run in "Integer Mode" when running PI-I2S DACs.
With e.g. 44.1khz we'd run the Mash mode, causing higher jitter then Integer mode..
I wasn't aware of it until now.
Unfortunately 99% of all music is.... ....yep, 44.1khz.
All that seem to apply to the DACs, which are slaved to PI2 I2S, such as Mamboberry, iQaudio etc.. I don't know though, if that also applies to the DAC+ Pro. I don't think so!??!
Conclusion:
It seems that running Integer Mode leads to lower jitter.
If that's the case I'd say that resampling the data to e.g. 32bit/48khz might be really beneficial.
Again. I don't know if that applies to the DAC+ Pro, since it uses its own clocks for I2S.
The final question then would be for the DACs affected:
What's worse, the extra jitter due to Mash mode or the resampling associated losses?
We need to figure it out!
Cheers
PS: I guess the Archphile patch refers to the new 50/50/100 blck_ratio setting. Beside that they had 24bit support disabled due to XBMC issues.
But all that seems to be solved now. The changes seem to be included in my latest 4.1 kernel download from last weekend.
They still have that S24_3LE/S24_LE terminology problem in the driver! They are just not in line with Alsa.
Last edited:
Agreed! Both make a difference!
Agreed, and that is why the DAC+ Pro SHOULD have a good theoretical advantage from an I2S jitter perspective. AFAIK, their use of the PCM51xx DACs' ability to run in Master mode with the Pi slaved to the Bit Clock should provide for integer-type processing for sampling rates other than 48, like 44.1.
At least that's what they say over on the HiFiBerry Forums. It may be worth more questions there. BTW, their driver's source code is available, I believe you can find a link in their forums or in their knowledgebase.
All other Pi-DACs have to deal with the extra jitter due to Mash mode.
The ES9022/23 ones do use the ESS ASRC which largely reduces the impact, but I hear the ESS DACs sound better when run synchronously.
The only other option is to do asynchronous re-clocking with something like an Ian FIFO (I have that in line to try) or what is done on the DAM DAC. But of course these options are MUCH more expensive than any Pi-DAC Hat combo available!
Dunno. You could see by trying the older HiFiBerry driver (which does not enable the Master/Slave mode) and resampling to 48.
Me, I'm betting full integer mode via the Master/Slave mode will win.
Very curious to see what you find if you get a chance to try this!
Greg in Mississippi
1.
There are two advantages related to the clock, as far as I see it.
a. The DAC+ Pro has (a) potentially better clock(s)
b. The DAC+ Pro potentially doesn't suffer MASH mode, because of its two clocks in master mode.
However:
The clock advantage of the DAC+ Pro might be eaten up by the rather poor power supply used for the clocks and/or DAC chip.
2.
The marketed jitter suppression in Sabre DACs never really seemed to work for me.
I also owned Twisted Pear stuff and other DACs. Every outside change made a difference.
I'd guess that my mentioned resampling approach, even on the Sabre based Mamboberry, might be well worth a try.
There are two advantages related to the clock, as far as I see it.
a. The DAC+ Pro has (a) potentially better clock(s)
b. The DAC+ Pro potentially doesn't suffer MASH mode, because of its two clocks in master mode.
However:
The clock advantage of the DAC+ Pro might be eaten up by the rather poor power supply used for the clocks and/or DAC chip.
2.
The marketed jitter suppression in Sabre DACs never really seemed to work for me.
I also owned Twisted Pear stuff and other DACs. Every outside change made a difference.
I'd guess that my mentioned resampling approach, even on the Sabre based Mamboberry, might be well worth a try.
Soundcheck,
I think we are in violent agreement, especially on the effectiveness (or lack there-of) Sabre DAC ASRC jitter suppression! I've had similar experiences with an ES9022 DAC card from EUVL.
I see three levels of clock sophistication in the available Pi-Hat DACs available:
Lowest - Use the non-integer mode clock of the stock Pi with no reclocking... IQAudio, Durio, etc.
Medium - Use the ESS ASRC - MamboBerry.
High - Reclocking using a custom driver, two clocks on the DAC hat, and the Master/Slave mode of the PCM51xx DAC chips to generate an integer-related bit clock which is used by the custom driver in the Pi - HiFiBerry DAC+ Pro.
And then I SUSPECT that there are two even better options available:
Higher - Use a custom driver and two clocks as above, but use a well-designed and implemented hardware set to generate integer-related bitclock.
Highest - As above, but implement with isolation chips AND clean-side hardware reclocking
And one option that will depend on how well it is implemented is FIFO-style reclocking like Ian's FIFO and the FPGA FIFO in the Soekris DAM DAC. I suspect that these will vary in effectiveness depending on the implementation (I suspect the Ian-hybrid-FPGA-SW style to be better than the all FPGA of the DAM, especially given the clock Soekris uses and the ability to pick better, lower-jitter ones for the Ian FIFO setup) and I haven't heard a hard and fast on how well these actually work in eliminating upstream source jitter affects in the real world.
Very curious to hear what you find with the resampling.
Greg in Mississippi
I think we are in violent agreement, especially on the effectiveness (or lack there-of) Sabre DAC ASRC jitter suppression! I've had similar experiences with an ES9022 DAC card from EUVL.
I see three levels of clock sophistication in the available Pi-Hat DACs available:
Lowest - Use the non-integer mode clock of the stock Pi with no reclocking... IQAudio, Durio, etc.
Medium - Use the ESS ASRC - MamboBerry.
High - Reclocking using a custom driver, two clocks on the DAC hat, and the Master/Slave mode of the PCM51xx DAC chips to generate an integer-related bit clock which is used by the custom driver in the Pi - HiFiBerry DAC+ Pro.
And then I SUSPECT that there are two even better options available:
Higher - Use a custom driver and two clocks as above, but use a well-designed and implemented hardware set to generate integer-related bitclock.
Highest - As above, but implement with isolation chips AND clean-side hardware reclocking
And one option that will depend on how well it is implemented is FIFO-style reclocking like Ian's FIFO and the FPGA FIFO in the Soekris DAM DAC. I suspect that these will vary in effectiveness depending on the implementation (I suspect the Ian-hybrid-FPGA-SW style to be better than the all FPGA of the DAM, especially given the clock Soekris uses and the ability to pick better, lower-jitter ones for the Ian FIFO setup) and I haven't heard a hard and fast on how well these actually work in eliminating upstream source jitter affects in the real world.
Very curious to hear what you find with the resampling.
Greg in Mississippi
Last edited:
It is 100% unlikely assuming you are using the "stock" in-kernel drivers, with the exception of simple-card, that pre-populate bclk_ratio, that you would ever be using 50/50/100 ratio.
Code:
/* If bclk_ratio already set, use that one. */
if (dev->bclk_ratio)
bclk_ratio = dev->bclk_ratio;No idea. Unable to say what their patch was meant to do, to start with. The patch file in their git, was a blank file. You'd have to ask the people responsible for the patch, and that's not me.
Yes.... And No.....
Theorically, this is correct.
But some DAC in "slave mode" has PLL to correct the signal.
So.... Without measurements, no way to say if jitter is present in the system.
This is correct. This is why I've suggested for people with a "slave DAC" / RPI to parameter the audio player at 48khz and let the player do the resampling.
I can not confirm (no neasurements available) but I think the result should be better because the resampling done by software if more "perfect" than the interrupt reclocking.
So main issue: There are no measurements available to say what solution is better: slave mode with PLL, master mode, resampling????
Soundcheck,
Before you start throwing the "proprietary" talk at me, please understand that I want to help you. I have the answers you seek. But the fact is simple, they do give the holder of such info a commercial advantage and someone paid for the time that was involved to gain that knowledge.
The problem being, that I was paid for the testing/research and writing of drivers. I am not in a position to just open source that work. I need to obtain the permission of the company that paid me to publish what I have, whether that be modified existing and new drivers or measurements.
As far as I am aware, no-one else has made a driver publicly available optimised for the Pi/Sabre combo, everyone else selling Sabre boards for the Pi just piggybacks on the original Berry PCM5102 config for their Sabre DAC HAT.
Hi,
Couple of questions:
(1) What exactly is the issue thats being addressed by what Archphile Mike refers to as the "true 24 bit" i2s patch?
(2) Is this same as what you are referring to as 50/50/100 bit clock ratio patch?
(3) Is there a Linux kernel that already has patch rolled in? I was looking through change logs for kernels 4.1.17 through 4.4.1 and did not see any reference.
Btw, really interesting thread. I hope the device manuf incorporate some of the mods mentioned here in their product lineup.
Regards,
moodeaudio.org
Tim
Tim,
I've no idea what this "true 24 bit" is about. Possibly S24_3LE, (24 bit in 3 byte, rather than S24_LE, 3 byte and one byte padding), but that is just me speculating. If someone can provide a link to the Archphile patch, it would help!
I've no idea what this "true 24 bit" is about. Possibly S24_3LE, (24 bit in 3 byte, rather than S24_LE, 3 byte and one byte padding), but that is just me speculating. If someone can provide a link to the Archphile patch, it would help!
Today I tried to fix the 24_3LE stuff myself. Quite a challenge for a part time hacker.
I had a talk with Florian - the guy who wrote the I2S driver.
He gave me a hint:
I basically replaced all occurrences of "S24_LE" with "S24_3LE" in the pcm512x/5102 and the I2S driver.
So far, so good. Everything compiled fine. And...
...aplay first time played a S24_3LE file. Great stuff.
At that point I didn't have my speakers (my Adams) on.
I then turned them on and...
.
...almost got deaf and almost suffered a heart-attack by a nasty 0db mess. Oh man.
My skills for sure are not sufficient to cover all that.
My guess. They never really tested 24bit streams!!!! How???
S24_LE is actually a 32bit format in Alsa terms and S24_3LE was not supported by the drivers at all.
I'm wondering how native 24bit would have made it through Alsa under these conditions.
I had a talk with Florian - the guy who wrote the I2S driver.
He gave me a hint:
I basically replaced all occurrences of "S24_LE" with "S24_3LE" in the pcm512x/5102 and the I2S driver.
So far, so good. Everything compiled fine. And...
...aplay first time played a S24_3LE file. Great stuff.
At that point I didn't have my speakers (my Adams) on.
I then turned them on and...
.
...almost got deaf and almost suffered a heart-attack by a nasty 0db mess. Oh man.
My skills for sure are not sufficient to cover all that.
My guess. They never really tested 24bit streams!!!! How???
S24_LE is actually a 32bit format in Alsa terms and S24_3LE was not supported by the drivers at all.
I'm wondering how native 24bit would have made it through Alsa under these conditions.
Last edited:
Soundcheck, please don't ...... 24 bit audio is output bit perfect. That you are not understanding the what and why, or want something to be supported that currently isn't. ie. S24_3LE.... Neither here, nor there. You need it, (apparently), I have no need for it.
I have tested and captured 24 bit data to verify it being bitperfect using S24_LE with those drivers.
You should be able to fire-up squeezelite, having given it "-a ::24" as a command line option, with both DAC+Pro and Mambo and stock drivers. That works, right? Are you really using aplay to listen to music?
I don't buy your story!!! Perhaps I'm too stupid.
You don't bring up any logical explanation. The code - as far as I can translate it - says something different. Florian actually agreed to my position!
What I see is a very low level bug (kernel/driver) that forces others - application designers and users - to align accordingly.
Sooner or later something like this can end up in a total mess.
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.
aplay to me is the reference to check Alsa conformity. It clearly tells me if there's a problem with the driver or the app. Declaring aplay as nonsense tool makes me feel odd about your reasoning.
You don't bring up any logical explanation. The code - as far as I can translate it - says something different. Florian actually agreed to my position!
What I see is a very low level bug (kernel/driver) that forces others - application designers and users - to align accordingly.
Sooner or later something like this can end up in a total mess.
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.
aplay to me is the reference to check Alsa conformity. It clearly tells me if there's a problem with the driver or the app. Declaring aplay as nonsense tool makes me feel odd about your reasoning.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.