Just want to report back that with Ian's help my ESS Controller is fixed (loose pins on the GPIO connector).
Btw, anyone tried playing 352.8khz stream? When I play those using Roon it upsamples it to 384khz. I don't know why and can't seem to be able to disable the upsampling (DSP already disabled). Compared to the non-upsampled 192khz version the upsampled version clearly sounds worst (try the 2L high-res samples).
This is under DietPi so I wonder if other OS may be different.
Btw, anyone tried playing 352.8khz stream? When I play those using Roon it upsamples it to 384khz. I don't know why and can't seem to be able to disable the upsampling (DSP already disabled). Compared to the non-upsampled 192khz version the upsampled version clearly sounds worst (try the 2L high-res samples).
This is under DietPi so I wonder if other OS may be different.
Sabre DACs ususally won't benefit from upsampling from my experience.
This would mean that every upsampling would make things worse.
1. There is no lossless DSP
2. You'll put more load on a system
I do run upsampling on my system on a different DAC. Because the losses associated to upsampling
I consider less destructive then the losses associated to the rather mediocre on-DAC filters,
which happen to get bypassed at 352k8/384 - in my case - on my DAC.
Keep in mind though:
It's not about just any "upsampling". It's a science on it's own to find the best upsampler and the best settings!
I ended up writing my own resampler. And in the final tuning phase the whole result still becomes of matter of taste.
Sabre do offers a mode to bypass its internal oversampling filters as well. But that's a pretty intrusive configuration.
You'll also loose the volume control and mute functions if I recall it correctly.
And it would require to feed 8x fs rate = 352k8 on 44.1 material.
Which would then work for samplerates of 48k max. over RPI-I2S considering a max I2S rate of 384k.
Still. For a hardcore tweaker it might be a viable approach or try.
Of course Ian would have to make that OversamplingFilterBypass mode available through his controller panel.
Enjoy.
This would mean that every upsampling would make things worse.
1. There is no lossless DSP
2. You'll put more load on a system
I do run upsampling on my system on a different DAC. Because the losses associated to upsampling
I consider less destructive then the losses associated to the rather mediocre on-DAC filters,
which happen to get bypassed at 352k8/384 - in my case - on my DAC.
Keep in mind though:
It's not about just any "upsampling". It's a science on it's own to find the best upsampler and the best settings!
I ended up writing my own resampler. And in the final tuning phase the whole result still becomes of matter of taste.
Sabre do offers a mode to bypass its internal oversampling filters as well. But that's a pretty intrusive configuration.
You'll also loose the volume control and mute functions if I recall it correctly.
And it would require to feed 8x fs rate = 352k8 on 44.1 material.
Which would then work for samplerates of 48k max. over RPI-I2S considering a max I2S rate of 384k.
Still. For a hardcore tweaker it might be a viable approach or try.
Of course Ian would have to make that OversamplingFilterBypass mode available through his controller panel.
Enjoy.
Last edited:
Still recovering from dizzyness
after reading your recent posts.Look. All this is mostly about opinions. And I'm sure Ian is well aware that his DAC - as a dedicated RPI solution - has a weak spot on the driver side.
There are not that many RPI HATS without driver out there. This is not an opinion. That's a fact. It just wouldn't make much sense to offer a 2nd controller IF.
And this is not just some hot-air bullshitting. I just supported a manufacturer on the driver subject. Small manufacturers usually just don't have the knowledge, manpower and capital to get the driver business properly in place.
Of course the way Ian is running his project will work for some die-hard DIY audio nerds. As long as Ian is happy with that... ...what can I say.
Enjoy.
Hmmh. What could that possibly mean?
1+1=?
Dear soundcheck. I respect you and I have always liked you but recently you sound demanding and condescending which is not nice. You can do better, honestly.
Pointing facts that are obvious is ok but your words come a liiitle too aloof. Apologies, English is my third language and I might sound rude,not my intention but Ian made his choices, he got a lot of advice in the development stage and people had plenty of time to read what he offered and decide what, if and how many will buy. You could order just a cable as well. Ian is not a vendor, actually his stuff is really very well made and I consider it a bargain. He is definitely not making money from it, just sharing his work which is great because not many people do it.
Do you have something to share other than disappointment that he is not Allo or we need to guess what that means? Or if I am not able to guess would you give your opinion?
If you just want to stream PCM audio a basic I2S driver will do. There are plenty of basic drivers available on all OSes.
Even Ians HAT DAC works with these.
However.
If you want to access any internal registers of the DAC to access the usually numerous non-default settings you need a DAC specific driver. For ESS Sabre you need two. One for the onboard MCU and one for the operating system.
Some features are more some less relevant, some not relevant at all to the end user. The features relevant to the user are passed on to the OS driver.
The features relevant to the user, such as e.g. Sabre internal volume control, mute, or choice of oversampling filters, in-/output selection will be made accessible through that driver. OSes like piCorePlayer, Moode, Volumio make these features available on a GUI - if they are nice - and usually they are.
The problem with Sabre DACs. Every manufacturer has to write his own proprietary driver for the same DAC chip because of the NDAs every of the manufacturers have signed. All manufacturers must install an MCU on the DAC board to hide the access codes to the Sabre registers.
The OS driver they write can only speak to the MCU and not to the DAC chip. Now. Why is Ian not using the Katana driver? It's the same DAC. Yep. But's it's a proprietary
MCU firmware in between. I doubt Allo would be that nice to hand that MCU firmware out.
And all that skyrockets effort and cost for such a rather cheap DAC.
It can be done differently of course. In the early days quite some DAC
manufacturers were and still are using TI PCM51xx chips for the HAT DACs. Why?
HifiBerry had written a nice and solid driver for it. TI doesn't have that NDA policy in place.
And Hifiberry didn't care about piggybackers.
All a manufacturer had to do was building the DAC HW and piggybacking on the HifiBerry work.
Enjoy.
Last edited:
Let me solve that riddle.
I share a lot of stuff. And I contribute quite some stuff. More than many other people around here.
But my own resampler won't be shared. Sorry.
If u use sox, or some other nice tools, you'll make it quite far.
sox will still produce better results then certain on-DAC oversampling filters -
if you get the setup properly done. I've been using sox for quite some time
myself.
After all we - as usual - just talk about these tiny tiny changes that touch our audiophile hearts.
Enjoy.
Last edited:
I actually think Ian made smart move decoupuling his gear out of RPi. Katana is copuled to RPI and it will not scale beyond that and it is limited to RPI users. If Ian will design a receiver board of RPI footprint then he can say "good bye rpi" and scale up his business far beyond Allo is capale of, since he will be able to target much broader audience and still have RPI as an option.
I was reading Ian's ESS controller manual this morning, and although I haven't built mine yet, this looks to be a good solution.
You can use the rotary encoder or apple remote to set volume or to setup internal DAC registers. I plan to buy an apple remote, and then will be set. Maybe I'm old school, but I like using a remote for volume control, vs web based. But he also supports web based vol control, just not web based register changes.
Since I can do register changes with a remote or encoder, no biggie to me.
Randy
You can use the rotary encoder or apple remote to set volume or to setup internal DAC registers. I plan to buy an apple remote, and then will be set. Maybe I'm old school, but I like using a remote for volume control, vs web based. But he also supports web based vol control, just not web based register changes.
Since I can do register changes with a remote or encoder, no biggie to me.
Randy
Last edited:
IMO anyone can write a user-space control utility using I2C (e.g. usb arduino loaded with firmata) and control the registers described in the driver source code GitHub - royno/Rpi-ES90x8-DAC or older GitHub - luoyi/Rpi-ES9018K2M-DAC . The register constants are well named in those sources. It may not fit ESS license though.
Nothing for me, I am not going to pay for a chip whose manufacturer refuses to publish a user guide for. I do not see any IP in register specific addresses and values. All DACs are configured/controlled in a similar manner.
Nothing for me, I am not going to pay for a chip whose manufacturer refuses to publish a user guide for. I do not see any IP in register specific addresses and values. All DACs are configured/controlled in a similar manner.
My guess would be they are trying to prevent competitors from making me-too dac chips that are sabre register and pin compatible.
Several weird conclusions here.
1. Ian made a move into the RPI world for a reason. Without driver he just did it half the way though.
By providing an external universal DAC board he could have simply let the RPI integration go. Everybody could have attached 4 wires to the PI GPIO I2S pins and would have been set. The same way as you'd do with a Soekris DAC.
2. It wasn't a smart move to leave out the driver. He just didn't have any other choice! The rather complex DAC needs an external control option.
And he couldn't provide a driver. Which was not a big deal, since there is
a rather small DIYA groupbuy crowd out there who'd accept a very basic control option anyhow.
A smart move would have been to make use of the Katana driver for his MCU/DAC.
3. Funny. You seriously believe Allo is sleeping on their butts?
Meanwhile Allo is usually two steps ahead of us. They do appreciate a hint here and there.
And if they do something, it follows pretty much an "All In" attitude and that includes proper SW support. The Katana driver was fully integrated into the official RPI kernel quite some time before the DAC was officially launched.
And as far as I recall, Allo already mentioned some time ago to be working on an USB DAC. Do Not underestimate Allo!
Enjoy.
Several weird conclusions here.
1. Ian made a move into the RPI world for a reason. Without driver he just did it half the way though.
By providing an external universal DAC board he could have simply let the RPI integration go. Everybody could have attached 4 wires to the PI GPIO I2S pins and would have been set. The same way as you'd do with a Soekris DAC.
2. It wasn't a smart move to leave out the driver. He just didn't have any other choice! The rather complex DAC needs an external control option.
And he couldn't provide a driver. Which was not a big deal, since there is
a rather small DIYA groupbuy crowd out there who'd accept a very basic control option anyhow.
A smart move would have been to make use of the Katana driver for his MCU/DAC.
3. Funny. You seriously believe Allo is sleeping on their butts?
Meanwhile Allo is usually two steps ahead of us. They do appreciate a hint here and there.
And if they do something, it follows pretty much an "All In" attitude and that includes proper SW support. The Katana driver was fully integrated into the official RPI kernel quite some time before the DAC was officially launched.
And as far as I recall, Allo already mentioned some time ago to be working on an USB DAC. Do Not underestimate Allo!
Enjoy.
haha …"1. Ian made a move into the RPI world for a reason. Without driver he just did it half the way though."
Really? Maybe it was his smart move to surf on RPIs HATs hype to scale up his business on that and then go even beyond … Maybe coupling your product just to one platform is dead end in business terms … unless this was your conscious choice and you want that.
"2. It wasn't a smart move to leave out the driver. He just didn't have any other choice! The rather complex DAC needs an external control option."
Really? He did not have another choice? Are you sure? How do you know that? Maybe it actually was his conscious choice to have every piece of production (including software and its release) process under control to be able to eventually sell his IP to some audio company in the future … or Maybe he just does not like Linux
None knows what drove him …"3. Funny. You seriously believe Allo is sleeping on their butts?"
I do not. How do you know I do? Nor I underestimate Allo. I got couple of gears from them. I really like them. I just realized at some point that for my case (TIDAL, usability, great sound) I do not need RPI nor any hassle related to that. Since Allo is totally coupled to RPI I just lost interested in their products, although I think they are very good! Ian's products simply fit my requirements best in this regard and I love it.
We actually do not know what drove Allo nor Ian when they started dev on their products at that time nor we know what really drives them now.
We just have our weird conclusions over that …
Apparently they both have fans and !fans
which is great!If "We" includes me I've to disappoint you. Since years I do maintain a quite close contact to this or that manufacturer (Ian is not one of them).
From time to time I'm even involved in the design/pre-launch processes.
And I do know about Ian's position, since we had the driver discussion some months back. Somebody made a driver available.
I didn't have the impression that Ian wasn't interested at first. Unfortunately the driver in question was a driver that would have
caused a serious ESS Sabre copyright violation. That driver would have never made it into the official RPI kernel. That's a fact.
I do think at the point in time Ian's driver ambition dropped great time. And that's now my opinion.
Because I've havn't seen any driver discussions ever since.
However. Times might change. I hope so.
As I said earlier. Perhaps Ian is able to do some reverse engineering on the Katana driver and update his
MCU firmware accordingly. It's the same DAC. It's pretty much the same functionality. And the driver is accessible.
If that's possible. That could save him a hell lot of work.
Until then I keep lurking around here once in a while and enjoy my Allo stuff.
Enjoy.
Last edited: