According to the club administrator's ugly homepage, both he and the author use machine translation to understand English sentences. The author's posts are originally written in Japanese as can be seen here with his real name, requesting source code disclosure.
Raspberry Pi Support Questions
That is the reason why their posts are not to the point.
Asking for source from others and accepting only qualified members, hard to understand...
Raspberry Pi Support Questions
That is the reason why their posts are not to the point.
Asking for source from others and accepting only qualified members, hard to understand...
Hi babalius,
I'm just appalled at your vindictive nature. And your points are all out of focus.
I think #297 and #297 indicate that you are a regular poster on a disreputable anonymous forum in Japan.
There are many characteristics commonly found on anonymous forums such as
Self-contradictory points
logical fallacy
and unfounded accusations.
You seem to have a weakness for English slang and not to be able to use slang expressions as well as you do in Japanese.
It would be silly to argue with you every time, so I'll just point out one thing.
On the contrary, doesn't this indicate that he was willing to release the source code three years ago? He has declared that he is willing to release the source code, as evidenced by a series of exchanges in this thread.
I should add that I'm not an administrator on the R&D Club, just a member who volunteer to accept membership.
I'm just appalled at your vindictive nature. And your points are all out of focus.
I think #297 and #297 indicate that you are a regular poster on a disreputable anonymous forum in Japan.
There are many characteristics commonly found on anonymous forums such as
Self-contradictory points
logical fallacy
and unfounded accusations.
You seem to have a weakness for English slang and not to be able to use slang expressions as well as you do in Japanese.
It would be silly to argue with you every time, so I'll just point out one thing.
On the contrary, doesn't this indicate that he was willing to release the source code three years ago? He has declared that he is willing to release the source code, as evidenced by a series of exchanges in this thread.
I should add that I'm not an administrator on the R&D Club, just a member who volunteer to accept membership.
diyAudio - tos
The process of getting an R&D club membership, judged by a simple volunteer and not directly by the author, is causing distress and incontvenience to me.
How old are you, 6?
I think you need to find another playground with kids of the same age...
I really believe the clock redesign in this project is very unique and could propel the RPi audio to levels targeted by the complicated FIFO + clock hats which introduce very long latency. But unfortunately the project also carries a baggage of technically unfounded changes and an unsustainable development model which will likely cause the clever clocking principle to stay limited to the secretive group of never-questioning users.
Maybe someone else will take the inspiration and implement the precise clock options to the upstream where they belong.
Maybe someone else will take the inspiration and implement the precise clock options to the upstream where they belong.
There is no chance you could reach the "levels targeted by the complicated FIFO + clock hats", in any case you should start from a PLL rather than a precise clock, that's not the right way in digital to analog conversion.
The PLL heavily affects the short term stability.
The only chance to avoid latency and get good results is to slave the Raspberry to the DAC clock.
The PLL heavily affects the short term stability.
The only chance to avoid latency and get good results is to slave the Raspberry to the DAC clock.
Hi babalius,
Tell me where I said that I take the liberty of dictating the registration of members. #289 I wrote
Tell me where I said that I take the liberty of dictating the registration of members. #289 I wrote
Please don't take your own interpretation.
I know, sorry for expressing myself incorrectly. The correct would be "heading in the same direction".
The problem with RPi is not PLL but the way audio clocks are achieved in standard setups by fractional dividers - basically by averaging two frequencies, yielding an approximately correct frequency. Look at MASH description on page 102 of the datasheet https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf . IMO that is why Ian's chart shows the two peaks at https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-533.html#post6284897 .
On the other hand, PLL for clocks is used in well-reputed soundcards e.g. Asus Xonar has a single crystal for both 48kHz (exact) and 44.1kHz (PLLed) frequency families. I am not saying it is ideal, but certainly provides a very decent result, way better than the MASH.
The setup here generates 638.976MHz for 48kHz and 632.2176MHz for 44.1kHz families by PLL from the 27MHz (RPi3)/54MHz (RPi4) crystal and integer-divides these for the corresponding BCLK, LRCLK. The resultant jitter/phase noise remains to be measured, though...
The problem with RPi is not PLL but the way audio clocks are achieved in standard setups by fractional dividers - basically by averaging two frequencies, yielding an approximately correct frequency. Look at MASH description on page 102 of the datasheet https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf . IMO that is why Ian's chart shows the two peaks at https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-533.html#post6284897 .
On the other hand, PLL for clocks is used in well-reputed soundcards e.g. Asus Xonar has a single crystal for both 48kHz (exact) and 44.1kHz (PLLed) frequency families. I am not saying it is ideal, but certainly provides a very decent result, way better than the MASH.
The setup here generates 638.976MHz for 48kHz and 632.2176MHz for 44.1kHz families by PLL from the 27MHz (RPi3)/54MHz (RPi4) crystal and integer-divides these for the corresponding BCLK, LRCLK. The resultant jitter/phase noise remains to be measured, though...
There IMO is no PLL problem!!!
There are 60-70$ hats slaving the PI and show single digit ps (or better) jitter levels.
For USB DACs this is irrelevant anyhow.
Bottom line. If you're up for quality sound what really matters is to get yourself a quality audio IF with proper engineering in place.
Enjoy.
There are 60-70$ hats slaving the PI and show single digit ps (or better) jitter levels.
For USB DACs this is irrelevant anyhow.
Bottom line. If you're up for quality sound what really matters is to get yourself a quality audio IF with proper engineering in place.
Enjoy.
I agree with this. I get the impression that the system image is built by hand, from sources that are only partly under version control. As the project continues to evolve, unless something is done it will become unmaintainable.
So you mean that just because it's possible to buy a more advanced dac, there is no point in improving the situation for the simple ones that rely on the pll?
That doesn't mean there is no pll problem, just that you don't think it's worth doing anything about it.
I understood this, but such high frequencies (more than 600 MHz) have poor short term stability, thus the dividers cannot remove the jitter, neither the PLL can do the job, it just adds more close in noise.
A single crystal is the best way to save money, but not the ideal way to manage two sample rate frequencies.
That's the reason I suggest to get the Raspberry slaved to the DAC clock, with a dedicated oscillator for each sample rate.
This way the MCK, LRK and BCK are no longer affected by the jitter coming from the Raspberry. It simply provides data when requested, but it does not manages the timing.
Obviously this way needs hardware as well as software, the Raspberry cannot do the job itself.
Hi soundcheck,
I understand your conclusion, which was arrived at after much trial and error.
I also think you should buy a DAC with a good DDC and plug it in via USB.
I'd like to continue to do some more DIY.
Just the other day I was interested in the Sync mode of the ESS chip and I tweaked the DAC HAT driver to evaluate the sound quality.
I should have tried it sooner.
With all these new discoveries, isn't DIY fun!
i enjoy it
Yep.
Because you won't achieve ""symphonic"" sound qualities by using cheap audio devices. 🙄
And this is what this project is all about. Isn't it. 😉
To me that PLL tweak IMO is a wasted effort.
Beside that, I do see tendencies where HATs are no longer first choice devices in the RPI universe anyhow, when it comes to RPI4 in particular (with its quite good USB setup).
Enjoy.
Because you won't achieve ""symphonic"" sound qualities by using cheap audio devices. 🙄
And this is what this project is all about. Isn't it. 😉
To me that PLL tweak IMO is a wasted effort.
Beside that, I do see tendencies where HATs are no longer first choice devices in the RPI universe anyhow, when it comes to RPI4 in particular (with its quite good USB setup).
Enjoy.
Sorry but I have not understood, which USB DAC are you pointing out?
Please, elaborate your concept.
So you think to get good signals from the USB of the RPI4?
I'm very curious, please explain your digital chain.
Have a look at my blog. My system is listed over there in detail.
And yes. I consider myself one of those following the HAT hype over here from the beginning. And to me it's time to move on.
USB is back in the game. Allo Revolution. Soncoz DACs. Asf Asf. Join that with an Allo Shanti and you'll be set.
And yes. I consider myself one of those following the HAT hype over here from the beginning. And to me it's time to move on.
USB is back in the game. Allo Revolution. Soncoz DACs. Asf Asf. Join that with an Allo Shanti and you'll be set.
Sorry but I have no time to read your blog.
Anyway I see the Allo Revolution that can operate in sync and async mode.
In sync mode from the USB is exactly the same I did suggest for the Raspberry, slaving it to the DAC.
In async mode you are using the PLL of the SABRE DAC, not much different than using the PLL of the Raspberry.
Anyway I see the Allo Revolution that can operate in sync and async mode.
In sync mode from the USB is exactly the same I did suggest for the Raspberry, slaving it to the DAC.
In async mode you are using the PLL of the SABRE DAC, not much different than using the PLL of the Raspberry.
I said I listed my system over there.
Anyway. This is a total mixup getting close to total nonsense. Sorry. Can't take you serious.