What I want to do
Build the ultimate PC audio solution : a no-compromise DAC which handles multichannel audio up to 24-192, custom upsampling filters, volume control, brutefir active XO in the PC, easy to use, appears like a soundcard to a Linux JACK system, press Play on the media player and it just works.
How
* FPGA module connected to PC through 100Base-T Ethernet :
- provides packetized audio streaming ability.
- FPGA contains a Microblaze CPU and peripherals.
- 4-8 megabytes of SDRAM on board.
- FPGA can do signal processing including 4-8x oversampling from 44.1k.
* DAC module
- onboard low-jitter master clocks for 44.1k and 48k based sample rates
- no ASRC
- FPGA module and PC are slaved to this master clock
- DAC, I/V
- and volume control (probably LDR) controlled by PC
* PC software
- Linux JACK driver to appear as a soundcard
- standard JACK-aware media player application, user choice
Current status
- Working prototype with Suzaku FPGA module connected to my old DAC
- no JACK driver
- oversampling with sox
- it works and sounds good
- URL : http://audio.peufeu.com
In development
Version 2 with a new, improved FPGA module should be done and working by October 15. FPGA module has LAN9117 with magnetics, Spartan 3E-500 and 32-bit fast SDRAM. All available FPGA IOs will be routed to a Hirose connector.
What you can do
I will build the FPGA modules, do the embedded coding and HDL, to get a fully functioning ethernet audio streaming system. I will publish the UDP protocol specs and pinouts.
I would like to create a team to work on this project. Things that have to be done are :
- write a driver for JACK (needs C/C++ and linux programming skills)
- write a driver for Windows
- build DACs and experiment
- software to display the songs titles on a LCD
- replay gain handling with onboard volume control
- remote control
- etc.
If you are interested, please post.
Project timeline
Phase 1 (up to end of October 2007) :
I build a FPGA module prototype and make it work.
Phase 2 :
Gather a team of motivated people. FPGA module group buy. I will handle the manufacturing, since this is likely to involve some pretty funky SMD soldering. So, I will build the stuff and sell the modules at parts cost (about $100).
I would like to gather maybe 3-5 people, everyone having the same module and hacking. You probably all have some DAC boards somewhere to connect to it
Phase 3 :
Design of a DAC mainboard and plugin modules for various DACs, I/Vs, volume controls, etc. The idea is to get an experimental platform to try many DAC chips, IV design candidates. Once common connector pinouts are decided, anyone can build plug-ins, listen, mail them to buddies for other listening tests, etc. This should be pretty interesting !
Phase 4 :
Decide the best plug-ins, make a one-board DAC, and go !
Who's in ?
Build the ultimate PC audio solution : a no-compromise DAC which handles multichannel audio up to 24-192, custom upsampling filters, volume control, brutefir active XO in the PC, easy to use, appears like a soundcard to a Linux JACK system, press Play on the media player and it just works.
How
* FPGA module connected to PC through 100Base-T Ethernet :
- provides packetized audio streaming ability.
- FPGA contains a Microblaze CPU and peripherals.
- 4-8 megabytes of SDRAM on board.
- FPGA can do signal processing including 4-8x oversampling from 44.1k.
* DAC module
- onboard low-jitter master clocks for 44.1k and 48k based sample rates
- no ASRC
- FPGA module and PC are slaved to this master clock
- DAC, I/V
- and volume control (probably LDR) controlled by PC
* PC software
- Linux JACK driver to appear as a soundcard
- standard JACK-aware media player application, user choice
Current status
- Working prototype with Suzaku FPGA module connected to my old DAC
- no JACK driver
- oversampling with sox
- it works and sounds good
- URL : http://audio.peufeu.com
In development
Version 2 with a new, improved FPGA module should be done and working by October 15. FPGA module has LAN9117 with magnetics, Spartan 3E-500 and 32-bit fast SDRAM. All available FPGA IOs will be routed to a Hirose connector.
What you can do
I will build the FPGA modules, do the embedded coding and HDL, to get a fully functioning ethernet audio streaming system. I will publish the UDP protocol specs and pinouts.
I would like to create a team to work on this project. Things that have to be done are :
- write a driver for JACK (needs C/C++ and linux programming skills)
- write a driver for Windows
- build DACs and experiment
- software to display the songs titles on a LCD
- replay gain handling with onboard volume control
- remote control
- etc.
If you are interested, please post.
Project timeline
Phase 1 (up to end of October 2007) :
I build a FPGA module prototype and make it work.
Phase 2 :
Gather a team of motivated people. FPGA module group buy. I will handle the manufacturing, since this is likely to involve some pretty funky SMD soldering. So, I will build the stuff and sell the modules at parts cost (about $100).
I would like to gather maybe 3-5 people, everyone having the same module and hacking. You probably all have some DAC boards somewhere to connect to it
Phase 3 :
Design of a DAC mainboard and plugin modules for various DACs, I/Vs, volume controls, etc. The idea is to get an experimental platform to try many DAC chips, IV design candidates. Once common connector pinouts are decided, anyone can build plug-ins, listen, mail them to buddies for other listening tests, etc. This should be pretty interesting !
Phase 4 :
Decide the best plug-ins, make a one-board DAC, and go !
Who's in ?
Peufeu, you need to track down the 8-year-old kid from this article:
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=201202710&printable=true
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=201202710&printable=true
I would love to be in to.
but I fear I will not be much useful to you as I have not anywhere near your knowledge.
Do you accept me peufeu ?
In fact I would like to buy a soldered FPGA module from you (at about cost price would be great).
That way I could try it on my computer and tell you if the module is working !!
Also count me in for the future DAC and plugin boards test and chip I/V comparisons.
This project is exactly what I need and what I was dreaming of !
Eric, France
but I fear I will not be much useful to you as I have not anywhere near your knowledge.
Do you accept me peufeu ?
In fact I would like to buy a soldered FPGA module from you (at about cost price would be great).
That way I could try it on my computer and tell you if the module is working !!
Also count me in for the future DAC and plugin boards test and chip I/V comparisons.
This project is exactly what I need and what I was dreaming of !
Eric, France
Hi peufeu.
I tried Jack. It really made my sound worse compared to my tweaked ALSA USB audio
driver.
So better be careful not to waste too much time on Jack drivers if you really want to go for the ultimate PC solution.
Using a standard player is IMO also the questionable path here if you're after best sound.
The no-frill apporach is to my experience a must for best sound. Why don't you just use brutefir as a player as I am doing it.
I am still wondering if the whole FGPA thing is worth the effort. The other day Takashi Iwai form ALSA was mentioning something about an externally
clocked USB bus. That would be really cool, if that ever comes to life!
However. Good luck with your project.
Cheers
Klaus
I tried Jack. It really made my sound worse compared to my tweaked ALSA USB audio
driver.
So better be careful not to waste too much time on Jack drivers if you really want to go for the ultimate PC solution.
Using a standard player is IMO also the questionable path here if you're after best sound.
The no-frill apporach is to my experience a must for best sound. Why don't you just use brutefir as a player as I am doing it.
I am still wondering if the whole FGPA thing is worth the effort. The other day Takashi Iwai form ALSA was mentioning something about an externally
clocked USB bus. That would be really cool, if that ever comes to life!
However. Good luck with your project.
Cheers
Klaus
Thanks for your interest
There is no point in building several copies of the device before the first FPGA board is working, thoroughly tested, including full ethernet bandwidth etc. I'd hate to screw up and have a few non-working PCBs, considering the price of 4 layer prototypes.
So, the only help I would need right now is proof-reading the FPGA design and PCB to check if I screwed up. Or, if you own a PCB fab, or digikey I have to rethink the layout a bit, again...
When the first one works, now, we can talk, and hack
soundcheck :
- did you make the "bit exact test" ? (ie play something, record it, check for differences, by looping back SPDIF output to input). For instance some sample rate conversion, or truncation, may slip in in unexpected places, and you can detect that.
There is no point in building several copies of the device before the first FPGA board is working, thoroughly tested, including full ethernet bandwidth etc. I'd hate to screw up and have a few non-working PCBs, considering the price of 4 layer prototypes.
So, the only help I would need right now is proof-reading the FPGA design and PCB to check if I screwed up. Or, if you own a PCB fab, or digikey
I have to rethink the layout a bit, again...When the first one works, now, we can talk, and hack
soundcheck :
- did you make the "bit exact test" ? (ie play something, record it, check for differences, by looping back SPDIF output to input). For instance some sample rate conversion, or truncation, may slip in in unexpected places, and you can detect that.
peufeu said:Thanks for your interest
soundcheck :
- did you make the "bit exact test" ? (ie play something, record it, check for differences, by looping back SPDIF output to input). For instance some sample rate conversion, or truncation, may slip in in unexpected places, and you can detect that.
Bit-Perfection: Always a nice issue to discuss!
My PCM2707 wouldn't even support looping the stream.
However. I do not have dmix in the loop. Nothing will be resampled.
I also read quite some people done the "Bit-Perfect-Looping-Test" on setups you
wouldn't expect bit-perfection if you listen to them.
Assuming a bit-perfect stream, what I do - and I really dont know how to test this in my setup, it IMO won't tell you anything on the induced non-lineartieries and/or jitter, thus sound quality.
Cheers
Sure, it doesn't guarantee good sound, but bit-perfect test avoids some turd-polishing
Like, especially on windows when some unexpected processing is added without the user's knowledge. Or CD players that mess with the data.
You removed all the fluff from your system, so you should be safe
It's mandatory anyway for DIY (I looped back my I2S output to I2S input to test), cause it's easy to slip a bit or get the shift registers wrong and end up with 15-bit audio.
Like, especially on windows when some unexpected processing is added without the user's knowledge. Or CD players that mess with the data.
You removed all the fluff from your system, so you should be safe
It's mandatory anyway for DIY (I looped back my I2S output to I2S input to test), cause it's easy to slip a bit or get the shift registers wrong and end up with 15-bit audio.
soundcheck said:
When you get 8 channels of 24/96 playback from your approach with NO sensitivity to activity on the PC, then go ahead and wonder. Considering the degree of effort you seem to have spent on getting 2 channel 16/44.1 working and yet STILL have a very high degree of sensitivity to system activity, I fail to see why you would 'wonder' about this approach.
I'm with peufeu on this - if the playback quality on your system is sensitive to software activity on the system, that is a flaw. It is NOT a sign of transparency or quality.
If the only way to get decent audio out of a PC is to throw away all the cool software that makes a PC better than a CD player in the first place, why bother? Really, what you seem to have done is moved away from a CD player to a PC, and then spent a whole lot of time and effort trying to turn the PC back into a CD player again, simply because your clock is overly sensitive to external influence.
The answer seems simple - use a clock architecture that is immune to influence from the PC. Once that is done, then you can use the PC with all the cool software available without having to worry one bit about audio quality. This is the primary point of peufeu's design.
I don't really think the clock is the main advantage of peufeu's approach, although his opinion may certainly differ. No matter what, the "analog" quality of clock will have to be good no matter where the timing or synchronization occurs.
To me, the real benefit of using the FPGA is to enable some playback customization that simply can't be done right now without buying very expensive hardware/software (for example, the DEQX system). The application I would like to see is an arbitrary digital Xover/channel splitter. What do I mean? Well, first, assume my source is bog standard 2-channel wav or mp3 (16-bit/44.1 "redbook" CD). I have two 3-way speakers (tweeter/midrange/woofer) and two subwoofers. I would like to split my source so that I send a specific subband to each speaker driver. This means I will need to "break out" the wav files into 2*3+2=8 channels, each of which has been passed through the appropriate digital filter. Then each channel can go to a dedicated DAC (meaning I need either 8 mono DACs or 4 stereo DAC's), followed by amplification, and then routed directly to the speaker driver without the need for analog crossover, which is now present in 99% of speakers. Of course, I would DIY the speakers so that each driver can be fed independently. For me, this is the ultimate goal. I've thought about getting a DEQX, but it's currently beyond my financial means, and my DIY ethic says there must be a better way. This is the light that I view peufeu's project. Althought I must say, I would prefer a wireless approach, to really separate the computer (physically, at least) from the stereo system. That way I could route the channels all over the place. If the SqueezeBox (which is based around an FPGA approach) allowed me to breakout the subbands, I'd do it that way, but I don't see Slim Devices coming out with such a player for a long time, if ever. There simply is not enough demand.
To me, the real benefit of using the FPGA is to enable some playback customization that simply can't be done right now without buying very expensive hardware/software (for example, the DEQX system). The application I would like to see is an arbitrary digital Xover/channel splitter. What do I mean? Well, first, assume my source is bog standard 2-channel wav or mp3 (16-bit/44.1 "redbook" CD). I have two 3-way speakers (tweeter/midrange/woofer) and two subwoofers. I would like to split my source so that I send a specific subband to each speaker driver. This means I will need to "break out" the wav files into 2*3+2=8 channels, each of which has been passed through the appropriate digital filter. Then each channel can go to a dedicated DAC (meaning I need either 8 mono DACs or 4 stereo DAC's), followed by amplification, and then routed directly to the speaker driver without the need for analog crossover, which is now present in 99% of speakers. Of course, I would DIY the speakers so that each driver can be fed independently. For me, this is the ultimate goal. I've thought about getting a DEQX, but it's currently beyond my financial means, and my DIY ethic says there must be a better way. This is the light that I view peufeu's project. Althought I must say, I would prefer a wireless approach, to really separate the computer (physically, at least) from the stereo system. That way I could route the channels all over the place. If the SqueezeBox (which is based around an FPGA approach) allowed me to breakout the subbands, I'd do it that way, but I don't see Slim Devices coming out with such a player for a long time, if ever. There simply is not enough demand.
> dwk123
You said the magic word : architecture ! Architecture design is when many problems can be created, or eliminated. I could rather replace hard to solve problems (like, transmitting/recovering a low jitter clock, starting with a high jitter clock from a PC) by simpler problems, while at the same time getting more features
> ezkcdude :
> I don't really think the clock is the main advantage of peufeu's approach, although his opinion may certainly differ
Well, it's an advantage, but the other advantage of a FPGA based design is flexibility, ie. you can do pretty much anything you want provided it fits in the chip, and there are no silly restrictions on "standard" sample rates or number of bits or channels ; I could stream DSD over ethernet just changing a few lines in the verilog code to turn a I2S I/O into a DSD I/O, for instance, and playback DSD from harddisk, even rip it (this would require a brain transplant from a SACD player though).
For your digital active XO application, things would get a bit hairy to implement it in a FPGA or DSP because, in order to avoid the need of huge processing power, you need to resort to a FFT based algorithm like BruteFIR, instead of simple convolution. It can be done in a FPGA or DSP, of course, but since there is a PC with a harddisk in it to store the music, the PC might as well run BruteFIR, since it works very well and you only have to install it, much work time is saved.
However, a FPGA is well suited to implementing custom oversampling filters (like slow rolloff, etc) instead of using digital filter chips. This way, 44.1k can be oversampled to 176.4k before feeding it to a PCM1704, for instance, and the filter response, which affects sound quality, can be modified easily and tweaked.
Wireless would be nice, but it brings other problems, it isn't simple to stick a radio transceiver close to low noise audio circuits and not get some RF pickup. Also, Ethernet has isolation transformers, so no ground loops are created. Finally, I tried my device on a WiFi network, and had packet loss problems : WiFi loses some packets, so you have to handle retransmission etc, which means larger buffers and higher latencies, or dropouts.
You said the magic word : architecture ! Architecture design is when many problems can be created, or eliminated. I could rather replace hard to solve problems (like, transmitting/recovering a low jitter clock, starting with a high jitter clock from a PC) by simpler problems, while at the same time getting more features
> ezkcdude :
> I don't really think the clock is the main advantage of peufeu's approach, although his opinion may certainly differ
Well, it's an advantage, but the other advantage of a FPGA based design is flexibility, ie. you can do pretty much anything you want provided it fits in the chip, and there are no silly restrictions on "standard" sample rates or number of bits or channels ; I could stream DSD over ethernet just changing a few lines in the verilog code to turn a I2S I/O into a DSD I/O, for instance, and playback DSD from harddisk, even rip it (this would require a brain transplant from a SACD player though).
For your digital active XO application, things would get a bit hairy to implement it in a FPGA or DSP because, in order to avoid the need of huge processing power, you need to resort to a FFT based algorithm like BruteFIR, instead of simple convolution. It can be done in a FPGA or DSP, of course, but since there is a PC with a harddisk in it to store the music, the PC might as well run BruteFIR, since it works very well and you only have to install it, much work time is saved.
However, a FPGA is well suited to implementing custom oversampling filters (like slow rolloff, etc) instead of using digital filter chips. This way, 44.1k can be oversampled to 176.4k before feeding it to a PCM1704, for instance, and the filter response, which affects sound quality, can be modified easily and tweaked.
Wireless would be nice, but it brings other problems, it isn't simple to stick a radio transceiver close to low noise audio circuits and not get some RF pickup. Also, Ethernet has isolation transformers, so no ground loops are created. Finally, I tried my device on a WiFi network, and had packet loss problems : WiFi loses some packets, so you have to handle retransmission etc, which means larger buffers and higher latencies, or dropouts.
ezkcdude said:
The idea is to write a JACK driver for my ethernet audio device, so that it appears like a standard soundcard, and BruteFIR can use it directly. There will be no need for a soundcard in the PC.
Bernhard said:
I tried this, it works well, but playing from a harddisk is so much more user-friendly... I got more than 1000 CDs (not pirate stuff) and it was becoming unmanageable, so I put everything in FLAC.
peufeu said:
I didn't know what JACK is, so I looked it up - lo and behold - you definitely have a good idea IMO.
OTOH, I'm wondering if I could use OS X's Core Audio to do much of what you are after. See here,
http://developer.apple.com/document...f/doc/uid/TP40003577-CH3-DontLinkElementID_21
and here:
http://developer.apple.com/document...1.html#//apple_ref/doc/uid/TP40003577-CH8-SW2
Just a thought.
I really like your'e idea with a ethernet reciever for highend audio... very cool.
Peufeu, there is something which i don't understand through!
I assume you feed the i2s input, at youre dac, with 4wires (gnd,bck,fs,data)? am i right here ?.
Then the clock at the i2s reciever must be 22,57.. for normal cd-quality ?
It's just because, the i2s reciever on my dddac is 2,8224. so i don't know howto fix this issue (on another i2s recieverboard perhaps?). Actually i dont know how this work at all.
I am btw, really glad for my dddac.
Hope you can answer my quistion here.
Jesper.
Peufeu, there is something which i don't understand through!
I assume you feed the i2s input, at youre dac, with 4wires (gnd,bck,fs,data)? am i right here ?.
Then the clock at the i2s reciever must be 22,57.. for normal cd-quality ?
It's just because, the i2s reciever on my dddac is 2,8224. so i don't know howto fix this issue (on another i2s recieverboard perhaps?). Actually i dont know how this work at all.
I am btw, really glad for my dddac.
Hope you can answer my quistion here.
Jesper.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.