• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

New FIFO buffer for RPI/SBCs

People use the 3.3V for other things, not sound related or powering things sound related, even on audio HAT hardware. It needs to be there. Kali might not be HAT compliant or using an EEPROM, but something plugged into Kali could be. There is the expectation of both 5V and 3.3V supplies from the Pi. It needs to be "duplicated" on Kali, IMHO. This isn't an optional thing.

I get @cdsgames point on excluding the 3.3v (sourced from the pi), the nice sound improvements come from bypassing this on the D+PRO, Digi+, and Digi+PRO

Maybe provide it with an LT3xxx reg?

Also... I measured the 3.3V on the Kali... there's weird low ~.5 volts on it (it actually semi powers the Digi+, the LED is lit & dim)
 
Last edited:
I get it ..but in my opinion once you get the Kali , Dac and amp on RPI , you dont need that 3.3v. What you have its an excellent audio player and that's all that it will do. Remove Kali and do something else with your RPI..

It's possible that I am wrong , but its what I think.



People use the 3.3V for other things, not sound related or powering things sound related, even on audio HAT hardware. It needs to be there. Kali might not be HAT compliant or using an EEPROM, but something plugged into Kali could be. There is the expectation of both 5V and 3.3V supplies from the Pi. It needs to be "duplicated" on Kali, IMHO. This isn't an optional thing.
 
Thanks! Haha! The slave option does in fact... work. :D

Haha. Knew it would come in handy for something. That PR was me at my most tactful...

"This card has master clock. Why would anyone want to run it in slave mode?"
Me says, "Some users have found the Pi's "jittered to hell" clock to sound better. "

I'll start throwing different sample rates at it.

I tested, (by ear only so far, ie. does it produce sound), 44k1/48k/88k2/96k/176k4/192k @ 16 and 32 bit depths. Will be interested if you get anything other than "garble" @ 352k and 384k assuming you are running a kernel with the 384k support patched-in.
 
I get it ..but in my opinion once you get the Kali , Dac and amp on RPI , you dont need that 3.3v. What you have its an excellent audio player and that's all that it will do. Remove Kali and do something else with your RPI..

It's possible that I am wrong , but its what I think.

Don't discount the fact that I think most people will not want your complete reclocker/DAC/AMP stack. The re-clocker is the HOT product. ;) There are a large number of people out there already (potential customers) with DAC boards that run in slave mode, that could be pointed to your re-clocker board as a way to upgrade them.......

Me personally, I'd never buy another board based on anything smelling like a TI PCM5xxx series chipset. But that's me..... Same goes with your AMP board. I'm not being rude, I've just been around the block a few times. I'll take a an B&O ICE module any day of the week if I'm forced to take something ClassD......

But I can see there might be people out there, for whom your complete stack of products might make sense.

PS. Not trying to cause offence. Just telling it the way I see it.
 
Hi Greg ,

I believe so (jumper removed means that RPi and Kali need to be powered separately)

However I still think that powering Kali (and RPI) from Kali jack (suporting 3A) its the better solution, still your requirements might be specific..

I agree on 3.3v. Clive makes a good point thinking about "other" shields , but if you have Kali then you need a DAC + Amp...nothing else. Then 3.3v its not needed.

Scott,
CDSGAMES,

So I can feed 5v into the Kali with the jumper on and it will power the R-Pi or I can remove the jumper & then must power the R-Pi separately, correct? My plan is to use the later pretty much exclusively, that's what I'm setup for.

Finally, I'm personally ambivalent about no 3.3v feed from the Kali, whether it's a feed-through from the Pi or locally generated.

On one hand that will limit the number of situations where it will work. On the other hand, IMHO, using the 3.3v from the Pi to provide power to a DAC (or S/PDIF interface board) is a surefire way to not get very good sound. If you do decide to enable it in a later iteration, PLEASE generate it with a local LDO.

Greg in Mississippi
 
I agree on 3.3v. Clive makes a good point thinking about "other" shields , but if you have Kali then you need a DAC + Amp...nothing else. Then 3.3v its not needed.

Your DAC board might not use the 3.3V, but other DAC boards (of course, other DAC boards are available), have additional functionality other than just the DAC chip. eg. rotary encoder or IR receiver.

The Kali needs to be "transparent". Aside from "messing with" (is that a technical term????) the 4x I2S pins, which of course is the reason for its existence, every other pin needs to be passed through, IMHO.
 
Clive ,I am not taking offense to your points...especially since they are good ones. Way of looking at things...there are many ways.

You say there are DACs out there that run as masters and they matter... In my opinion they dont . They are poorly designed .

I agree with TI Dacs ICs...but try our Piano 2.1. Its not the IC , not only the analog implementation but mostly the DSP that makes the magic..separating the frequencies in the digital domain ...you have to listen to it.

However if you want to use it with a better DAC (buffalo maybe?) we have a small PCB where you can tap i2s on the pin header and use it on the DAC of your choice.

Regarding AMP...again I agree but let me say this. Even the best ICE module needs a good PSU. So we incorporated the capacitance multiplier and tpa3118 (one of the best amp icas far as bang for the $) and the sum its bigger than the parts..

So I convinced my guys to release a driver...but its very old , based on some old kernel. Interested in some old code ?



Don't discount the fact that I think most people will not want your complete reclocker/DAC/AMP stack. The re-clocker is the HOT product. ;) There are a large number of people out there already (potential customers) with DAC boards that run in slave mode, that could be pointed to your re-clocker board as a way to upgrade them.......

Me personally, I'd never buy another board based on anything smelling like a TI PCM5xxx series chipset. But that's me..... Same goes with your AMP board. I'm not being rude, I've just been around the block a few times. I'll take a an B&O ICE module any day of the week if I'm forced to take something ClassD......

But I can see there might be people out there, for whom your complete stack of products might make sense.

PS. Not trying to cause offence. Just telling it the way I see it.
 
Clive ,I am not taking offense to your points...especially since they are good ones. Way of looking at things...there are many ways.

Sure.

You say there are DACs out there that run as masters and they matter... In my opinion they dont . They are poorly designed .

Hmmm. Be careful. There are at least 2x boards/HATs out there that are master, and one of them I designed, that I know there is no way in hell you have heard. Yes, the commonly available "Pro" options are a joke!

I agree with TI Dacs ICs...but try our Piano 2.1. Its not the IC , not only the analog implementation but mostly the DSP that makes the magic..separating the frequencies in the digital domain ...you have to listen to it.

If I had a penny for everytime someone told me that listening to their version of a TI PCM5xxx series DAC was going to change my mind about hardware based on TI PCM5xxx series DAC chips......

However if you want to use it with a better DAC (buffalo maybe?) we have a small PCB where you can tap i2s on the pin header and use it on the DAC of your choice.

What like the PCB Ian did for the Pi header to tap the I2S pins and allow UFL connections? ;)

Regarding AMP...again I agree but let me say this. Even the best ICE module needs a good PSU. So we incorporated the capacitance multiplier and tpa3118 (one of the best amp icas far as bang for the $) and the sum its bigger than the parts..

You are preaching to someone you are never going to convert to solid state amplification, whether it be by capacitor multipliers or bribery.... LOL.

So I convinced my guys to release a driver...but its very old , based on some old kernel. Interested in some old code ?

Old source code? Yes!!!! Just show me what you got, and as I already said, I'll try and get it to a point where it complies to kernel coding standards (if it doesn't already) and the RPi guys will accept it for inclusion in their kernel git.

Some of the guys here might be interested in an image or binary driver. But I'm not. I'll wait for the source code. If I have to drag it kicking and screaming to make it compile with 4.4.20 or 4.7.3, so be it!
 
Sure.



Hmmm. Be careful. There are at least 2x boards/HATs out there that are master, and one of them I designed, that I know there is no way in hell you have heard. Yes, the commonly available "Pro" options are a joke!

Agreed. The commonly available are a joke..cannot comment on something that's not public.



If I had a penny for everytime someone told me that listening to their version of a TI PCM5xxx series DAC was going to change my mind about hardware based on TI PCM5xxx series DAC chips......


I might be wrong (my wife tells me it happens often) but I still think that xover in digital domains makes a big difference no matter what dac IC is used..



What like the PCB Ian did for the Pi header to tap the I2S pins and allow UFL connections? ;)

Exactly like Ians.



You are preaching to someone you are never going to convert to solid state amplification, whether it be by capacitor multipliers or bribery.... LOL.

You are a lost cause then .


Old source code? Yes!!!! Just show me what you got, and as I already said, I'll try and get it to a point where it complies to kernel coding standards (if it doesn't already) and the RPi guys will accept it for inclusion in their kernel git.


Email sent.


Some of the guys here might be interested in an image or binary driver. But I'm not. I'll wait for the source code. If I have to drag it kicking and screaming to make it compile with 4.4.20 or 4.7.3, so be it!
 
To all reviewers :

Every DAC ic has a specific "sound" ... ess sabre (nice one) r2r (even nicer I think) , ti dac (ehm) and you might like one better than another.

However the Piano 2.1 its not about the DAC IC and the "how warm " the sound is. The Piano 2.1 separates the frequency in digital domain thus sending 80hz (you can chose from 60-150Hz) and higher to your LR speakers and the rest to your subwoofer .

So I am not talking about "color" of the sound...I am saying that your LR speakers will only handle the frequencies they were designed for (lower frequencies sent to your LR will only interfere with the sound coming out)

Thats the main advantage of Piano 2.1...if you don't have a subwoofer you can still use the system as a 2.0 since your LR speakers are NOT supposed to have 10-80hz going in.

Everyone talks about the sound of the DAC ic...but how about the sound coming from your speakers...dont you think that might be important ?

Sometimes we look at pictures at pixel details and forget its the whole image thats important.

I think that digital xover (4 pole) stands as an equal (at least) to IC DAC "color"

My 2 cents.
 

TNT

Member
Joined 2003
Paid Member
Ultimate solution is that the DAC shall be master as in this case the osc can be placed really close (mm) to the DAC chip. Then a fifo is needed in order to be able to use synchronous connection interfaces like s/pdif where the fifo takes up the differences between the clocks.

Note that FIFO and reclocking done for 2 different reasons. Recklocking can be done without fifo.

Can the fifo design be made to also work as set to slave i.e. the DAC is master?

//
 
Scott,

If you PM me your address, I can send you an IQAudio R-Pi DAC to try.

Thanks Greg! Further in the thread the D+Pro can run in slave mode, so I'm set for now.
Also, I'm very curious to hear your impressions with the Digi+ on the Kali to your DAC. Was very surprised to hear that the Digi+ runs in master mode! I figured it used one of the Wolfson chips in slave mode. Or maybe it is the lack of a 3.3v feed that's causing it fits? If that's the case, you won't get it running without some extra fiddling!

It's a WM8804 chip. I'm reading up now to see if it can be run in slave mode.

The digi+ is very good --> only once using piZERO/LT3xxx power supplies/piCorePlayer (I use it every day on my main setup) Check the SBAF i2s/pi threads... we are in the middle of things now...
(maybe talk about it there? Don't want to derail this thread)

But as you see... can't run master mode Hat's (so no Digi+ or Digi+PRO)
 
Last edited:
Ok ultimate solution ?

A well designed DAC as master yes osc next to dac ic. (good dac ic)

However I think that FIFO is the ultimate "RTOS"...basically the SBC will only work as a front end and reclocker will have all data send on time every time. (no delays , no interrupts )

Kali 2 is being designed. Cannot comment too much yet. Give me 4 weeks..but yes it will accept DAC as master .I will start a thread and will design it with the community..



Ultimate solution is that the DAC shall be master as in this case the osc can be placed really close (mm) to the DAC chip. Then a fifo is needed in order to be able to use synchronous connection interfaces like s/pdif where the fifo takes up the differences between the clocks.

Note that FIFO and reclocking done for 2 different reasons. Recklocking can be done without fifo.

Can the fifo design be made to also work as set to slave i.e. the DAC is master?

//
 
So... pop off the 2 mute LED's? @clivem, are you planning on doing this?

Having had a quick look at the "old driver" code, I'm thinking about software rather than soldering irons....

If I can get a slave I2C address, knock-up an overlay, piggyback on IQ or HB machine driver, forget about the DSP, crossover and 2.1 for the moment, and just get it playing 2 channel stereo. I think incorporating the "driver" as-is, isn't going to happen without a major re-design once the "code police" get a look at it as it modifies an existing upstream driver. If I can compile a overlay and give you guys a dtbo to drop in /boot/overlays to get up and running without any driver mods, required for 2 channel stereo........

But yes, I was planning to attack the DAC board with soldering iron at some point....
 
I think that FIFO is the ultimate "RTOS"

That's the interesting/exciting thing here... you have it whittled down to a couple flip flops providing the i2s w/3ps jitter. Decoupling the OS!

Combine this and Ian's i2s decoupler stuff, hmmm!

Daniel at Hifiberry's gonna be... WTF? when I ask him for a Digi+Light (Slave mode) he just finished a master mode PRO. :p

SPDIF is still very useful for a lot of us :)

...Anyway, back to the stack!