Open Source DSP XOs - Page 25 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 14th May 2012, 03:20 PM   #241
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 105
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by Trevor White View Post
why do you have to interrupt the processor for each sample ?
Well at present I'm not using interrupts at all, rather polling for the next sample when I've finished with the current one. But perhaps in future I'll learn how to take advantage of the serial comms FIFO and then I'll just need to poll every 4 samples. At present I have a simple serial-parallel converter with a latch which only holds a single stereo sample.

Quote:
Surely this is not a requirement for an active crossover where a bit of latency is neither here nor there.
Quite so that its not a requirement, just it suits the particular SoC and method of interfacing to the incoming data rather well.
__________________
I have the advantage of having found out how hard it is to get to really know something... how easy it is to make mistakes and fool yourself. - Richard Feynman
  Reply With Quote
Old 15th May 2012, 10:17 AM   #242
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
Well at present I'm not using interrupts at all, rather polling for the next sample when I've finished with the current one. But perhaps in future I'll learn how to take advantage of the serial comms FIFO and then I'll just need to poll every 4 samples. At present I have a simple serial-parallel converter with a latch which only holds a single stereo sample.



Quite so that its not a requirement, just it suits the particular SoC and method of interfacing to the incoming data rather well.
you are throwing away valuable clock cycles doing the polling. It would probably add up to much more than the interrupt latency time where the processor could be doing other things.

what you're gaining on the roundabouts you are losing on the swings

Last edited by Trevor White; 15th May 2012 at 10:26 AM.
  Reply With Quote
Old 15th May 2012, 11:32 AM   #243
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Seems that abraxalito's approach is to use a Cortex-M0 as close as possible to the DAC, adding intelligence to a DAC. Consider a digital audio source like S/PDIF. Consider a stereo 3-way crossover. I guess abraxalito would use one S/PDIF receiver followed by three Cortex-M0 operating in parallel. Perhaps four when adding some global equalization, a long FIR perhaps. All Cortex-M0 see the LRCK (Fs) as main clock, also exploiting the BITCLK and LRCK. No MCLK needed as abraxalito prefears NOS DACs. The only functions abraxalito would add are 1) a high quality (analog) volume control driven by an infrared remote control and b) a message passing scheme for changing the filters coefficients. No doubt abraxalito would use an extra Cortex-M0 for this, dealing with the RC5 infrared receiver interrupts (the received bits) and dealing with a USB-device connexion, without disturbing the Cortex-M0s using as DSPs. The USB-device would connect on a USB-host (like a PC or a Tablet) running a GUI. From there would come the filter coefficients updates. The Cortex-M0 would then dispatch data to all other Cortex-M0s DSPs. For the interprocessor communication, knowing there could be five Cortex-M0s as data receivers (general equalizing, subwoofer, woofer, medium, tweeter), and knowing that abraxalito has a preference for a compact layout (less EMI) and a "no interrupt" scheme, I would advise him a monomaster to multislaves serial line, unidirectional, using a handmade SPI scheme (data, clock, enable) using bitbanging and polling, conveying 32 bit data words preceded by a 8-bit CPU identity prefix and a 24 bit local address for knowing where to write the data. With a bitrate equal to half the sampling frequency. Let's see what it becomes viewed from a Cortex-M0 DSP. When it has finished processing the sample, instead of waiting the new sample (polling), he polls the data communication serial line input, and processes any transition he sees over there. All Cortex-M0s used as DSP are wired in parallel, what's regarding the data communication line. Processing one transition is straightforward. This is a state-machine. In such state machine, you need to define states for reading the 8-bit CPU identity, comparing it to its own local CPU identity, reading the 24-bit address, reading the 32-bit data, and finally, writing the 32-bit data in local memory. You manage the communication at a bitrate 1/2 of Fs. If you need to update five 32-bit words, you will do five separate transactions. This guarantees that any Cortex-M0 doing the DSP, will only spend between 10 to 20 cycles for the communication, after having processed each audio sample.
  Reply With Quote
Old 15th May 2012, 12:32 PM   #244
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 105
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Up to this point, pretty much right steph_tsf

Quote:
Originally Posted by steph_tsf View Post
For the interprocessor communication, knowing there could be five Cortex-M0s as data receivers (general equalizing, subwoofer, woofer, medium, tweeter), and knowing that abraxalito has a preference for a compact layout (less EMI) and a "no interrupt" scheme, I would advise him a monomaster to multislaves serial line, unidirectional, using a handmade SPI scheme (data, clock, enable) using bitbanging and polling, conveying 32 bit data words preceded by a 8-bit CPU identity prefix and a 24 bit local address for knowing where to write the data.
I'm not at all a fan of bit-banging, that's one way to squander perfectly good CPU cycles which could be going towards a longer FIR filter. All the LPCs have UARTs so I'd explore using them before descending into the abyss of bit-banging The 9-bit (RS485) mode of the UART is a bit fiddly to use, but would allow some kind of addressing function.
__________________
I have the advantage of having found out how hard it is to get to really know something... how easy it is to make mistakes and fool yourself. - Richard Feynman
  Reply With Quote
Old 15th May 2012, 10:20 PM   #245
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
I'm not at all a fan of bit-banging, that's one way to squander perfectly good CPU cycles which could be going towards a longer FIR filter.
Disagree. The bitbang scheme I am advising only steals about 20 CPU cycles per audio sample, a hard to beat figure, with a maximal value that's deterministic. The only caveat is the relatively slow datacom bitrate (half the sampling frequency).
Quote:
Originally Posted by abraxalito View Post
All the LPCs have UARTs so I'd explore using them before descending into the abyss of bit-banging The 9-bit (RS485) mode of the UART is a bit fiddly to use, but would allow some kind of addressing function.
If you stick to a "no interrupt" scheme, you would poll the "new data available" flag from the UART. If the UART is configured for handling one byte at a time, and if you have a discipline like dealing with one datacom byte per audio sample, such scheme will only steal about 20 CPU cycles per sample with a maximal value that's deterministic, and deliver a 8 x bitrate compared to the above bitbang scheme. The flip side is the datacomm bit clock, a new clock in the system, potentially causing EMI in case there is some datacom trafic while the audio is on.

I'm afraid that if you want a "more efficient" datacomm, not dealing with one bit datacom per audio sample, or not dealing with one byte datacom per audio sample, you'll get a difficulty in predicting how many CPU cycles need to be allocated for the datacomm task, after having completed the DSP task.

Provided that the 1/2 Fs bitrate is enough, the bitbang scheme dealing with one bit datacom per audio sample is the most valuable scheme, compromise-free. In an audiophile context, it should be high on your list.

Last edited by steph_tsf; 15th May 2012 at 10:26 PM.
  Reply With Quote
Old 16th May 2012, 01:39 AM   #246
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 105
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by steph_tsf View Post
Disagree. The bitbang scheme I am advising only steals about 20 CPU cycles per audio sample, a hard to beat figure, with a maximal value that's deterministic. The only caveat is the relatively slow datacom bitrate (half the sampling frequency).
Ah I hadn't fully digested the fact that the bit banging was operating on such a low bitrate - objection dropped There's always an exception to the 'no bit banging' rule.

Quote:
I'm afraid that if you want a "more efficient" datacomm, not dealing with one bit datacom per audio sample, or not dealing with one byte datacom per audio sample, you'll get a difficulty in predicting how many CPU cycles need to be allocated for the datacomm task, after having completed the DSP task.
I haven't reached this point at the current level of detail in my own designs - I'm still at the broad brush stage. Thanks for pointing out the pitfall in determinacy.

Quote:
Provided that the 1/2 Fs bitrate is enough, the bitbang scheme dealing with one bit datacom per audio sample is the most valuable scheme, compromise-free. In an audiophile context, it should be high on your list.
Noted.
__________________
I have the advantage of having found out how hard it is to get to really know something... how easy it is to make mistakes and fool yourself. - Richard Feynman
  Reply With Quote
Old 16th May 2012, 01:53 AM   #247
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Another consideration in the single-sample versus sample-block processing is the opportunity to halt the processor to save power. Many embedded processors have the ability to halt the processor until a particular hardware event occurs. By matching several samples together in a block, not only can the firmware potentially use more efficient instructions (SIMD), but it becomes possible to handle hundreds of samples very quickly and then halt the processor while DMA collects the next block. A simple end-of-block interrupt from the DMA can wake the processor periodically. Granted, this requires that the hardware allow DMA between peripheral and memory to continue while the instruction stream is halted, and I'm sure that not all processors are designed for this.
  Reply With Quote
Old 16th May 2012, 04:38 AM   #248
diyAudio Member
 
Join Date: Jun 2004
Location: Connecticut
If for DIY you are counting clock cycles and writing asm you are wasting your time. Use something more powerful, write your code in C, and do something more productive with the time you saved.
  Reply With Quote
Old 16th May 2012, 04:40 AM   #249
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 105
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
What's unproductive about writing in assembler?

<edit> It looks to me that you've fundamentally missed the whole point of DIY. Its not about 'being productive' (as if that's an end in itself) is about having fun (i.e. producing a feeling of well-being) while being productive of things we can't buy commercially. At least that's how it works for me.
__________________
I have the advantage of having found out how hard it is to get to really know something... how easy it is to make mistakes and fool yourself. - Richard Feynman

Last edited by abraxalito; 16th May 2012 at 04:53 AM.
  Reply With Quote
Old 16th May 2012, 05:00 AM   #250
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
What's unproductive about writing in assembler?

<edit> It looks to me that you've fundamentally missed the whole point of DIY. Its not about 'being productive' (as if that's an end in itself) is about having fun (i.e. producing a feeling of well-being) while being productive of things we can't buy commercially. At least that's how it works for me.
assembler is not portable whereas C usually is.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volume / Source selector - open source project ? AuroraB Analog Line Level 22 22nd September 2012 02:21 PM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 02:26 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
Open Source, Open Architecture! zenmasterbrian Digital Source 185 23rd February 2007 10:35 PM


New To Site? Need Help?

All times are GMT. The time now is 04:01 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2