Hi guys,
thank you for the interest and kind words. I've populated the board and discovered few minor bugs. Had a bug in library symbol of clock buffer - swapped inputs. And I removed LEDs from power good pin of smps. Since it's not specified in datasheet its probably too weak for driving LEDs.
Impedance(and noise) of power supplies is really quite nice. I've quickly tried self-booting from EEPROM, It did not work. Dunno why, I haven't had a time to debug it(Xmas time, lot of get-to-gathers). I hope I'll be able to bring it to life during Xmas "holidays".
You have a really nice speakers and board Fio, Congratz!
Yes, Rpi can be used as I2S slave - see page 120 of datasheet . And some more info here - http://www.peteronion.org.uk/I2S/
I've been asked for schematics, I'll provide them once it's up & running, and tested. I'm not sure about the source files and Gerbers. If you'd like this to be open source, fire me a PM with few words why
I have received several inquires about buying the board.If you don't mind, I'd like to ask You few questions:
Would you be interested in bare PCB, or populated one?
In which version would you be more interested? In current smaller one, or the bigger one from the beginning of the thread(spdif in/out, powersupply for rpi onboard, eurocard format)?
Thank you,
Pitrsek
thank you for the interest and kind words. I've populated the board and discovered few minor bugs. Had a bug in library symbol of clock buffer - swapped inputs. And I removed LEDs from power good pin of smps. Since it's not specified in datasheet its probably too weak for driving LEDs.
Impedance(and noise) of power supplies is really quite nice. I've quickly tried self-booting from EEPROM, It did not work. Dunno why, I haven't had a time to debug it(Xmas time, lot of get-to-gathers). I hope I'll be able to bring it to life during Xmas "holidays".
You have a really nice speakers and board Fio, Congratz!
Yes, Rpi can be used as I2S slave - see page 120 of datasheet . And some more info here - http://www.peteronion.org.uk/I2S/
I've been asked for schematics, I'll provide them once it's up & running, and tested. I'm not sure about the source files and Gerbers. If you'd like this to be open source, fire me a PM with few words why
I have received several inquires about buying the board.If you don't mind, I'd like to ask You few questions:
Would you be interested in bare PCB, or populated one?
In which version would you be more interested? In current smaller one, or the bigger one from the beginning of the thread(spdif in/out, powersupply for rpi onboard, eurocard format)?
Thank you,
Pitrsek
I will be very interesting buying a populated board - a bigger version with spdif in/out.
Really look farward to it.
Really look farward to it.
Hi guys,
thank you for the interest and kind words. I've populated the board and discovered few minor bugs. Had a bug in library symbol of clock buffer - swapped inputs. And I removed LEDs from power good pin of smps. Since it's not specified in datasheet its probably too weak for driving LEDs.
Impedance(and noise) of power supplies is really quite nice. I've quickly tried self-booting from EEPROM, It did not work. Dunno why, I haven't had a time to debug it(Xmas time, lot of get-to-gathers). I hope I'll be able to bring it to life during Xmas "holidays".
You have a really nice speakers and board Fio, Congratz!
Yes, Rpi can be used as I2S slave - see page 120 of datasheet . And some more info here - http://www.peteronion.org.uk/I2S/
I've been asked for schematics, I'll provide them once it's up & running, and tested. I'm not sure about the source files and Gerbers. If you'd like this to be open source, fire me a PM with few words why
I have received several inquires about buying the board.If you don't mind, I'd like to ask You few questions:
Would you be interested in bare PCB, or populated one?
In which version would you be more interested? In current smaller one, or the bigger one from the beginning of the thread(spdif in/out, powersupply for rpi onboard, eurocard format)?
Thank you,
Pitrsek
This is correct, and hifiberry is selling a new DAC+ PRO for Rpi in master mode.
They also made the driver.
https://www.hifiberry.com/dacplus/
But I can't see any review or measurements
regards,
Hey guys,
The DSP is alive and well, I've hacked logic analyzer(saleae clone) that got same IC on it as USBi. I can talk to it, program the eeprom and so on. Outptus are nice on scope, I'll try to connect DAC tomorrow. I've found two more mistakes - EEPROM was write protected, SPDIF input was missing coupling cap. Oh, and had to clean up soldering on some places(shorts).
Happy new year!!
The DSP is alive and well, I've hacked logic analyzer(saleae clone) that got same IC on it as USBi. I can talk to it, program the eeprom and so on. Outptus are nice on scope, I'll try to connect DAC tomorrow. I've found two more mistakes - EEPROM was write protected, SPDIF input was missing coupling cap. Oh, and had to clean up soldering on some places(shorts).
Happy new year!!
I am interested in assembled board. It is quite impossible to do by hand that DSP chip, everything else is OK for manual soldering, but not chip. I think you would be safer offering only assembled boards. The smaller version would be my choice.
Happy New Year to all!
This is a really interesting project, thanks for all the great work on this. 
+1 on pre-soldered DSP and any/all other super fine pitch. I think can handle SMD components down to 0805 without problem though.
I'm not completely clear on the differences between the two versions (are these the two final options, or can we wish for changes?). Here is my grand total wishlist:
1 R-Pi connection over I2S
1+ analog inputs for AUX use (can be on add-on card also)
1 USB-to-I2S bridge
First two are covered by both versions as far as I can tell.
I'm a bit of a noob when it comes to DSPs, so here are some dumb questions.
From the schematic in post #20 I presume there are two clock bases for selecting 44.1/48 kHz. How is selection handled? Can the R-Pi choose this through I2C?
If I want to hook up an external USB-to-I2S card, how is clock selection handled then? Then it must signal wanted clock base through some pin (and support clock slave mode). For these reasons I prefer to have an onboard USB bridge as I guess this would be easier to integrate.
BUT, the USB input is a bonus so I'd pretty much take any version.
+1 on pre-soldered DSP and any/all other super fine pitch. I think can handle SMD components down to 0805 without problem though.
I'm not completely clear on the differences between the two versions (are these the two final options, or can we wish for changes?). Here is my grand total wishlist:
1 R-Pi connection over I2S
1+ analog inputs for AUX use (can be on add-on card also)
1 USB-to-I2S bridge
First two are covered by both versions as far as I can tell.
I'm a bit of a noob when it comes to DSPs, so here are some dumb questions.
From the schematic in post #20 I presume there are two clock bases for selecting 44.1/48 kHz. How is selection handled? Can the R-Pi choose this through I2C?
If I want to hook up an external USB-to-I2S card, how is clock selection handled then? Then it must signal wanted clock base through some pin (and support clock slave mode). For these reasons I prefer to have an onboard USB bridge as I guess this would be easier to integrate.
BUT, the USB input is a bonus so I'd pretty much take any version.
great project Pitrsek, congrats
I'd be interested in whichever version (populated or not) you decide to provide. I feel confident on soldering smd but if more people in the community want the pcb populated then I'll go with.
cheers
Pepe
I'd be interested in whichever version (populated or not) you decide to provide. I feel confident on soldering smd but if more people in the community want the pcb populated then I'll go with.
cheers
Pepe
Hi guys,
thank you for the interest and kind words. I've populated the board and discovered few minor bugs. Had a bug in library symbol of clock buffer - swapped inputs. And I removed LEDs from power good pin of smps. Since it's not specified in datasheet its probably too weak for driving LEDs.
Impedance(and noise) of power supplies is really quite nice. I've quickly tried self-booting from EEPROM, It did not work. Dunno why, I haven't had a time to debug it(Xmas time, lot of get-to-gathers). I hope I'll be able to bring it to life during Xmas "holidays".
You have a really nice speakers and board Fio, Congratz!
Yes, Rpi can be used as I2S slave - see page 120 of datasheet . And some more info here - http://www.peteronion.org.uk/I2S/
I've been asked for schematics, I'll provide them once it's up & running, and tested. I'm not sure about the source files and Gerbers. If you'd like this to be open source, fire me a PM with few words why
I have received several inquires about buying the board.If you don't mind, I'd like to ask You few questions:
Would you be interested in bare PCB, or populated one?
In which version would you be more interested? In current smaller one, or the bigger one from the beginning of the thread(spdif in/out, powersupply for rpi onboard, eurocard format)?
Thank you,
Pitrsek
Thx lindamar
Thank you guys for the answers, keep 'em coming.
It works, my speakers are working again . FYI - very simple 2 way crossover - 5 biquad blocks @96khz, spdif input and ASCR - cca 6% of the dsp power. Now I need to finish speakers surface (raw MDF at the moment)
I'm still having problems with self booting - the EEPROM is properly loaded but the DSP will not start. I do suspect problem with sequencing/boot up. Hopefully I'll sort it out during the week. On the next weekend I'm planing testing it with Rpi. Oh and one more thing needs to be tested - GPIO&Aux ADC.
@Mjjg
I'm afraid there is only one clock on the board. I've dropped the second one in order to simplify it. I'm not a software guy, writing a linux driver that could change sampling freqency(and reprogram DSP) on the fly is WAY out of my league. If there is someone who can do it and would be interested in participating on it, please fire me a pm.
At the moment the idea is that RPi will be doing the re-sampling and DSP will run on single frequency(SPDIF is re-sampled anyway). The current version contain a clock multiplexer - so you can change clk to external one. I might keep in the final version, if there's enough interest?
USB input could be provided by plethora of available usb-to-i2s. I'm sorry I do not have plans for USB module at the moment. My goals at the moment are final version of DSP board + 8ch dac. Analog input might come in future, but I make no promises.
The only one major design work left on the DSP board is power supply for RPI and DSP(12V from external adapter to 5V) + power management(push button startup and stand by mode). Rest is just implementation of bugfixes and slight redesign. Hopefully.
Would you consider 1A for USB devices on RPI enough? I have found quite nice buck converter - L6986. The "problem" is that if I subtract consumption of RPi and DSP there is "only" something little over 1A available for USB devices. Enough for external hdd, Wifi and pheriperials, but not enough to supply full 500mA to all USB ports... Is there anyone who would consider this a problem?
I've started some work on the final version - incorporating some bugfixes, new format etc. Additionally, I've started to work on a DAC modle.
Hopefully I'll have more free time during the January and I'll be able to speed the thing up a bit
Pitrsek
Thank you guys for the answers, keep 'em coming.
It works
, my speakers are working again . FYI - very simple 2 way crossover - 5 biquad blocks @96khz, spdif input and ASCR - cca 6% of the dsp power. Now I need to finish speakers surface (raw MDF at the moment)I'm still having problems with self booting - the EEPROM is properly loaded but the DSP will not start. I do suspect problem with sequencing/boot up. Hopefully I'll sort it out during the week. On the next weekend I'm planing testing it with Rpi. Oh and one more thing needs to be tested - GPIO&Aux ADC.
@Mjjg
I'm afraid there is only one clock on the board. I've dropped the second one in order to simplify it. I'm not a software guy, writing a linux driver that could change sampling freqency(and reprogram DSP) on the fly is WAY out of my league. If there is someone who can do it and would be interested in participating on it, please fire me a pm.
At the moment the idea is that RPi will be doing the re-sampling and DSP will run on single frequency(SPDIF is re-sampled anyway). The current version contain a clock multiplexer - so you can change clk to external one. I might keep in the final version, if there's enough interest?
USB input could be provided by plethora of available usb-to-i2s. I'm sorry I do not have plans for USB module at the moment. My goals at the moment are final version of DSP board + 8ch dac. Analog input might come in future, but I make no promises.
The only one major design work left on the DSP board is power supply for RPI and DSP(12V from external adapter to 5V) + power management(push button startup and stand by mode). Rest is just implementation of bugfixes and slight redesign. Hopefully
.Would you consider 1A for USB devices on RPI enough? I have found quite nice buck converter - L6986. The "problem" is that if I subtract consumption of RPi and DSP there is "only" something little over 1A available for USB devices. Enough for external hdd, Wifi and pheriperials, but not enough to supply full 500mA to all USB ports... Is there anyone who would consider this a problem?
I've started some work on the final version - incorporating some bugfixes, new format etc. Additionally, I've started to work on a DAC modle.
Hopefully I'll have more free time during the January and I'll be able to speed the thing up a bit
Pitrsek
Attachments
I'll reply here instead of a PM in case someone finds the info useful. I'm afraid I'm not that much of a software guy either so writing my own kernel driver is probably not going to happen. But I looked up the HifiBerry DAC. That has two clocks which are controlled by the R-Pi through I2C if I understand it correctly. So if it's possible to do a solution which is HifiBerry compatible we could use that driver. I haven't been able to find any specifics about how they do it, but I could fire up that driver and measure what comes out if you want. It would be preferable if someone who actually owns a HifiBerry DAC could measure this though(anyone?). There is still the problem of reprogramming the DSP of course but I think that can be solved.
I understand if you want to keep things simple. I'd probably be interested in buying a board anyway, and then save the fancy stuff for a DSP project of my own. I have an idea about how to implement all this, but the changes are quite large compared to your design so I thinks it's out of the question here. I'll draw something up and fire you a PM about it in case you're interested.
Switching MCLK of ADAU will change core frequency 294.912<->293.5296 (for example), this will have influence on system fs as well.
So you need to stop the core (maybe perform a reset), have a new stable clock, reload program compiled at new fs and new PLL settings and change registers in AD/DA as well.
This is a typical job for additional uC on DSP board to simplify the setup. You really have to take care on reset behavior, or mute DA separately by uC.
This will also limit the support for different ICs, because every chip needs a unique initializing config.
Hifiberry has an onboard EEPROM ("Integrated EEPROM for automatic configuration"). If there is an EEPROM, there will be a uC as well.
But the available I2S out is pointing on the fact that no DA register changes are executed? (just a guesswork)
Maybe DA asynchronously?
So you need to stop the core (maybe perform a reset), have a new stable clock, reload program compiled at new fs and new PLL settings and change registers in AD/DA as well.
This is a typical job for additional uC on DSP board to simplify the setup. You really have to take care on reset behavior, or mute DA separately by uC.
This will also limit the support for different ICs, because every chip needs a unique initializing config.
Hifiberry has an onboard EEPROM ("Integrated EEPROM for automatic configuration"). If there is an EEPROM, there will be a uC as well.
But the available I2S out is pointing on the fact that no DA register changes are executed? (just a guesswork)
Maybe DA asynchronously?
Last edited:
Yes, a dedicated uC was my thinking as well. The reset sequence of the ADAU1452 isn't too complicated (from glancing the data sheet), but like you say, the DAC needs reinitializing too, which could limits the modular approach taken here. Mostly from a hardware point of view, since the firmware of the uC can be changed depending on the DAC used.
I guess no registers needs changing in the DAC, but the clock must be switched, so I guess this is what is being done over I2C. I'm pretty sure I've read somewhere that no re-sampling is performed for this DAC. There would be little point in having two clocks if it was, afaics. Any other sampling rate from the source material would be re-sampled to some fixed higher clock frequency. The EEPROM is probably used for HAT compliance.
Hello
, I'm very interested. Or we can skype if you prefer. I wanted to keep it simple mainly because it is "a one man affair", and I feel that I'm probably at the limit of what I can handle on my own(like finishing it in some reasonable(finite) time, not loosing interest in it on the way etc.). If you like the design so far and it is compatible with idea of your DSP project, maybe we can work on it to gather. Let's talk .
Small dedicated uC - that is certainly the possibility. I believe it could be done without the uC. If(really big IF) they are using some of the RPi gpio for switching the oscillators, we could use it. The signal would be routed to DSP, I2C switch and a timer/counter. Additionally there is one more eeprom - I2C switch selects which EEPROM is connected to I2C bus. So one EEProm for 44,1kHz, one for 48kHz/96kHz.
If there is a change on the RPi GPIO, the DSP will immediately mute the output(or DACs via I2C if its working already, they had a bug in the I2C) and the I2C switch would connect proper EEPROM to I2C bus(and disconnect the other) and the timer will start. After the defined delay, the proper clock is selected and DSP is restarted. If you are able to talk to your DACs over i2c the delay could be really small, if the DAC is in hw mode, the delay would be a little longer - in order to provide sufficient time to load "muted samples".
Don't get me wrong, small STM32 on the board would be definitely quite handy and the board would by way more universal, the thing is that at the moment there is no one who would program it.
I know a few people who could create the driver for Linux, alas they are all very occupied at the moment. I'll keep bugging them from time to time
If I may ask, please measure it. We might discover that they just toggle some GPIO to select right oscillator. Which would be really nice....
Yes, please do
, I'm very interested. Or we can skype if you prefer. I wanted to keep it simple mainly because it is "a one man affair", and I feel that I'm probably at the limit of what I can handle on my own(like finishing it in some reasonable(finite) time, not loosing interest in it on the way etc.). If you like the design so far and it is compatible with idea of your DSP project, maybe we can work on it to gather. Let's talk . Small dedicated uC - that is certainly the possibility. I believe it could be done without the uC. If(really big IF) they are using some of the RPi gpio for switching the oscillators, we could use it. The signal would be routed to DSP, I2C switch and a timer/counter. Additionally there is one more eeprom - I2C switch selects which EEPROM is connected to I2C bus. So one EEProm for 44,1kHz, one for 48kHz/96kHz.
If there is a change on the RPi GPIO, the DSP will immediately mute the output(or DACs via I2C if its working already, they had a bug in the I2C) and the I2C switch would connect proper EEPROM to I2C bus(and disconnect the other) and the timer will start. After the defined delay, the proper clock is selected and DSP is restarted. If you are able to talk to your DACs over i2c the delay could be really small, if the DAC is in hw mode, the delay would be a little longer - in order to provide sufficient time to load "muted samples".
Don't get me wrong, small STM32 on the board would be definitely quite handy and the board would by way more universal, the thing is that at the moment there is no one who would program it.
I know a few people who could create the driver for Linux, alas they are all very occupied at the moment
. I'll keep bugging them from time to timePitrsek, Fio, you've been PM'd
I'll try to do that ASAP. But it occurred to me that it probably won't work unless I have a hifiberry dac+ pro connected. I'll look into buying one if that's the case.
Well if the HifiBerry DAC works the way I think it does, they could start from that. Hell, maybe even I could do that modification. I do enough programing from time to time that it might be within my league (I mean, if it's just about changing how the frequency is signaled).
I'll try to do that ASAP. But it occurred to me that it probably won't work unless I have a hifiberry dac+ pro connected. I'll look into buying one if that's the case.
I know a few people who could create the driver for Linux, alas they are all very occupied at the moment
Well if the HifiBerry DAC works the way I think it does, they could start from that. Hell, maybe even I could do that modification. I do enough programing from time to time that it might be within my league (I mean, if it's just about changing how the frequency is signaled).
Hello
Small dedicated uC - that is certainly the possibility. I believe it could be done without the uC. If(really big IF) they are using some of the RPi gpio for switching the oscillators, we could use it. The signal would be routed to DSP, I2C switch and a timer/counter. Additionally there is one more eeprom - I2C switch selects which EEPROM is connected to I2C bus. So one EEProm for 44,1kHz, one for 48kHz/96kHz.
If there is a change on the RPi GPIO, the DSP will immediately mute the output(or DACs via I2C if its working already, they had a bug in the I2C) and the I2C switch would connect proper EEPROM to I2C bus(and disconnect the other) and the timer will start. After the defined delay, the proper clock is selected and DSP is restarted. If you are able to talk to your DACs over i2c the delay could be really small, if the DAC is in hw mode, the delay would be a little longer - in order to provide sufficient time to load "muted samples".
Yes yes, I think this is pretty much the way to go. Unfortunately it's not enough to know the which XTAL to use, we need to know the actual sampling frequency. Unless we can live with integer ratio resampling in the DSP, which would at least be an improvement.
Some questions about the DSP programming. From your post I assume you do this via EEPROM? Or do you use the RPi for that? If the RPi is used, there might be a simple way to do this. First some assumptions:
1. There will be multiple input modules.
2. Some want a fixed fs, some want to change fs (the RPi way be of either sort).
And here is what would take place.
1. An input wishes to change fs, and signals a FCHG event*.
2. The RPi detects this and if the input is currently the active one, it asks the input what frequency it wants**.
3. RPi resets DACs and DSP through I2C.
4. The RPi sets the master clock through GPIO, either to on board clock generator if the second XTAL is reintroduced, or an off board one.
5. RPi reprograms DSP with correct data for selected fs.
6. RPi enables DACs/DSP
*This could be either through a dedicated interrupt pin or I2C. If dedicated pin, they could all be connected open-drain on the DSP board. This mode could make it easier to use of-the-shelf USB boards, but I2C is simpler.
**If the FCHG event is signaled through I2C, this step can be skipped since the request will contain the wanted fs.
We could of course replace RPi in the above with any uC, but it's hard to squeeze in 8 different DSP programs into the non-volatile memory of a typical uC. So using the RPi is preferred i think, except it needs to boot before it can do anything, but a device like this will probably be always on. This is also a lot easier than messing around with multiple EEPROMS. Unless we can somehow change starting address of where the DSP reads in data. Or, use the program start address register in some clever way.
Yes, the plan is to self-boot DSP from eeprom, and use RPI as "dumb source".
I2c and reset will be connected so anyone with enough time and skill can boot DSP from RPI.
Personally I would not worry a bit about integral resampling. Heck my plan is to re-sample it on RPi and use only one clock.
There is quite some board estate in clock area on the new(eurocard format) board. So my proposal is that I would include option to populate 2nd crystal + switching circuitry + provide switch signal(logic 0=osc0, logic 1=osc1 ) from one of RPi GPIOs and I will route the signal also to one of DSP GPIos.
This should not require too much design effort and board estate. Si53360 is actually quite cheap, there is no reason to change it. I can connect two oscillators to one input of Si53360 and switch signal would just enable one whichever you want to use. Or you can reconfigure it via a jumper and switch signal changes between oscillator 1 and external input. Would this work for you? what do you think?
Pitrsek
I2c and reset will be connected so anyone with enough time and skill can boot DSP from RPI.
Personally I would not worry a bit about integral resampling. Heck my plan is to re-sample it on RPi and use only one clock
. There is quite some board estate in clock area on the new(eurocard format) board. So my proposal is that I would include option to populate 2nd crystal + switching circuitry + provide switch signal(logic 0=osc0, logic 1=osc1 ) from one of RPi GPIOs and I will route the signal also to one of DSP GPIos.
This should not require too much design effort and board estate. Si53360 is actually quite cheap, there is no reason to change it. I can connect two oscillators to one input of Si53360 and switch signal would just enable one whichever you want to use. Or you can reconfigure it via a jumper and switch signal changes between oscillator 1 and external input. Would this work for you? what do you think?
Pitrsek
That's great. I think I can implement all I want with those changes. Actually, programming from multiple EEPROMS might not be so hard after all, using an I2C switch like you said, if all ROMS are mounted on an addon board. That would be easy if your current EEPROM is in a DIL-8 package, but I guess it's not? Anyway, I'll manage that somehow. But with this option I could implement this either by EEPROM or RPi, options are great
I haven't measured the HifiBerry clock signaling yet, but I've looked at the source code of the linux driver. It looks like clocks are choosen using GPIO. The driver sets either pin 0 or pin 5 of one of the PCM512x GPIO ports. I just have to figure out what RPi pins that correspond to.
I haven't measured the HifiBerry clock signaling yet, but I've looked at the source code of the linux driver. It looks like clocks are choosen using GPIO. The driver sets either pin 0 or pin 5 of one of the PCM512x GPIO ports. I just have to figure out what RPi pins that correspond to.