Open Source DSP XOs - Page 41 - 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 23rd January 2013, 02:52 PM   #401
diyAudio Member
 
Join Date: Jun 2009
It's worth ABX testing between 16 and 24 bit; I started with similar assumptions but, to my surprise, found 24 bit was consistently preferable. Inspection of the filtering showed some phase quantization occuring in 16 bit allpass filtering that was above the threshold I've found to be audible. It's not, however, clear to me if that's the cause of the subjective preference or if something else is going on; proving a negative is difficult to start with and implementing, say, a signal path which is 16 bit in phase but 24 bit in magnitude isn't particularly feasible either.

Of course, if one's using DACs which only accept 16 bit words it's kind of a moot point.
  Reply With Quote
Old 23rd January 2013, 03:37 PM   #402
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
There might still be workaround, let's ask Infineon.

An example: The I2S streams are continuous. If you want to sample @48 kHz/24 bits (or even 32 bits) you just tell USIC to work at 96 kHz rate with 16 bit word length and 32-bit frame length. Then just divide the word clock to DAC or CODEC by two: Use a D-type flip-flop with LRCLK to CLK input and /Q output of FF to DATA input so Q output has the frequency divided by two, right? (How about phase?) Now XMC's USIC thinks it's working on different sample rate and word/frame length but does it really matter? No it doesn't. Only thing I'm worried about with this workaround is the propagation delay and the other possible timing problems causing jitter. In this case XMC is master, so steph_tsf's "3 x bidirectional I2S with the XMC4500 as slave connecting to a WM8580 or WM8581 codec" doesn't work as simply because the word clock (from WM8580) frequency should be doubled which isn't as simple (though shouldn't be difficult for anyone experienced, guess you just clock in some counter with SCLK and reset it at LRCLK and take out the new sync from correct output).

Well, I was propably too fast, above doesn't work properly because the left and right channel may be mixed up and swapped and phase delayed

Last edited by mhelin; 23rd January 2013 at 03:56 PM.
  Reply With Quote
Old 23rd January 2013, 07:29 PM   #403
diyAudio Member
 
Join Date: Jun 2009
Yeah, proper initialization of the LRCLK flip flop is important to avoid mix ups. It would have be a pretty awful flip flop to introduce enough jitter on the LRCLK to cause data misreads or significant noise injection into most the DACs, though it is something to be careful of in the special case of a DAC with an PLL that's doing clock recovery from LRCLK. In well implemented cases the MCLK would be local to the DAC and a copy routed up to XMC so I wouldn't worry about it too much though. Another option to look into would be bit bang the pin, possibly by programming a USIC to emit 2x16 zeros, then changing it over to 2x16 ones.

All of these solutions seem like reinventing SGPIO the hard way, though.
  Reply With Quote
Old 24th January 2013, 12:46 PM   #404
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
Quote:
Originally Posted by twest820 View Post

All of these solutions seem like reinventing SGPIO the hard way, though.
Yeah, but SGPIO is in it's own class. Did you know that it can be used also to send SPDIF and ADAT signals? Actually any continuous bit stream sender can do it, so with XMC parts one solution would be to encode that data to SPDIF format for sending to DAC (Differential Manchester encoding - Wikipedia, the free encyclopedia).

Now your idea of bitbanging got me thinking solution for the slave use case. Because of the (large) number of I2S channels one channel could be used to sample the original 64SCLK LRCLK from the master device so we could use these bits to identify which 32SCLK frames are from right and which from left channel.
  Reply With Quote
Old 25th January 2013, 03:33 PM   #405
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
Left message to Infineon forum to clarify data sheet. I though found after some reading that in the SCTR (shift control register) there is also a FLE field which is described "FLE [21:16], rwh, Frame Length: This bit field defines how many bits are transferred within a data frame. A data frame can consist of several concatenated data words". Also earlier it decribed about I2S protocol:
"17.6.1.2 Protocol Overview

An IIS connection supports transfers for two different data frames via the same data line, e.g. a data frames for the left audio channel and a data frame for the right audio channel. The word address signal WA is used to distinguish between the different data frames. Each data frame can consist of several data words."

So it seems that the WLE setting doesn't set total data frame length but just the bits to be transferred to data buffer for single data word. Anyway, the code generated by DAVE must be modified to be able to transfer 24-bit words, but otherwise all looks good (though must wait for what Infineon guys tell).
  Reply With Quote
Old 26th January 2013, 10:07 AM   #406
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
Now if these XMC devices are fine after all I would be really interested in the XMC4400 parts in LQFP64 package for diy boards.

http://www.infineon.com/cms/de/produ...380a41302f6c86

If I did read it correctly this time this part comes with four USIC channels (U0C0,U0C1,U1C0 and U1C1, most of the pins are available in ALT2 pinning, there arent so many alt pinning as in larger packages) which would be just enough, and the part is easier to solder (less pins).

Last edited by mhelin; 26th January 2013 at 10:17 AM.
  Reply With Quote
Old 1st February 2013, 02:10 AM   #407
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: 95
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Today I came across this guy using a RasPi to do real-time guitar effects :

GuitarExtended - Real-time guitar effects on Raspberry Pi with Pure Data and Arduino - YouTube

Seems he's using a package called 'Pure Data' and getting his audio in and out via a USB soundcard. According to the Pd information a couple of soundcards are supported, one is a $30 Behringer here : Amazon.com: Behringer UCA222 U-Control Ultra-Low Latency 2 In/2 Out USB Audio Interface with Digital Output And Downloadable Software Bundle: Musical Instruments

I haven't looked into it, but ISTM that if Pd can do guitar effects it might also be able to do XOs. Anyone interested in investigating this? Also I'm seeing a window of opportunity here for NOS ADCs and DACs because for these kinds of real-time applications, low latency is highly desirable
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 1st February 2013, 03:39 AM   #408
diyAudio Member
 
Join Date: Jun 2009
The RPi SoC uses a 700MHz ARM11 core so should be entirely capable of running an XO. The ATmega32 in the Arudino's just monitoring the stompboxen---you can find details in the details link of the video. One might try Filterview or MMQ as starting points for an implementation.

My electric guitar rig goes through two ADC+DAC stages. I'm not sure what one of them is as I haven't gotten around to taking the pedal apart yet but the other's a CS4272 running anywhere from 44.1 to 96. 44.1 is a little loose but 96 is fine. NOS would be overkill from a latency standpoint, though electric guitar is NOS friendly in that the amps usually roll off in the 4-5kHz range so the rig won't be too sensitive to the NOS sync envelope.

Quote:
Originally Posted by mhelin View Post
Did you know that it can be used also to send SPDIF and ADAT signals?
Given an appropriate PHY all serial interfaces pretty much look alike and aren't at all hard to handle in SGPIO up to its clock rate limit. Implementations using NRZI encodings (all speeds of USB, for example) can be a little fussy as the data rate on the wire is data dependent and the bit stuffing is most conveniently implemented in the PHY. But NRZI and other common enodings like 8b/10b (1394, SATA) can be done in software if one really has to. Manchester (SPDIF, 10MHz Ethernet) is easy as are unencoded links like I2S but for SPDIF you'll likely end up with a PHY down---I'd be surprised if the XMCs or LPC4300s have PLLs that can acquire an incoming stream at sufficient speed. So one might as well just ship I2S back to a Wolfson transciever and let it handle the encoding, driving the output, and getting levels right. Cirrus does make SPDIF transmitters but Wolfson's transceivers are cheaper and use the same amount of board space.

Quote:
Originally Posted by mhelin View Post
part is easier to solder (less pins).
I wouldn't sweat it; drag solder difficulty is a weak function of the number of pins on the package.
  Reply With Quote
Old 1st February 2013, 12:00 PM   #409
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
Quote:
Originally Posted by abraxalito View Post
Today I came across this guy using a RasPi to do real-time guitar effects :

GuitarExtended - Real-time guitar effects on Raspberry Pi with Pure Data and Arduino - YouTube
Noticed the same vid earlier, too.

I would rather use FAUST to generate C++ code and then optimize it for own use:

FAUST (programming language) - Wikipedia, the free encyclopedia
https://ccrma.stanford.edu/~jos/spf/aspf.pdf

Seem FAUST can also generate PD plugins so it may be the FX is originally coded in FAUST.

RPi, well is not a nice environment. It is using Broadcom closed source SoC where the GPU actually implements many system functions. There is no proper documentation, for an example when people have tried implementing simple PCM/I2S IRQ handler it doesn't respond to documented IRQ but to another one found by hacking (IRQ 55 is the documented one, IRQ 81 the one raised when I2S FIFO is empty/full). USB on RPi has got the only (allowed) FIQ level (non-maskable) IRQ, so USB devices seems to work if supported, but I2S audio for an example is difficult to get working at all or with latencies low enough for realtime use. Got to try the Behringer on because I've got such on my desk waiting for some use. Now if RPi just supported 24-bit 8-channel audio on HDMI (which is doesn't do as far as I know, but haven't tried either) it would make nice crossover system. Just get an inexpensive AV receiver with enough power and use it as multichannel power amp with RPi connected to it's HDMI input.

I've got the NGX LPC4330 Xplorer board (came with Keil ULINK-ME JTAG adapter), got to find out next how to build a proper power supply for the Asus H6 DAC board so I can start doing something with them (using breadboard and jumper wires to connect different modules). Guess LM1117-5.0/3.3 LDO's a fine for regulating the DAC voltages, aren't there any reasons for not using them? Seems there are zillions LDO to choose from, but don't know which are kind of standard like LM317/LM337 ones for op amp supplies.
  Reply With Quote
Old 1st February 2013, 01:23 PM   #410
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
hows your QFN soldering? the TPS7A4700/TPS7A3301 are unbeaten at the moment. +/-1.4-36Vout for the pair at up to 1A and as low as 4µVRMS. next down would be the little brothers TPS7A4901/TPS7A3001, which have the same voltage specs, while being a bit more diy friendly. They still have powerpad to solder under the part for heatsinking, but you can make a modified PCB pattern to allow hand soldering pretty easy by punching a couple vias through the powerpad to solder from underneath. they are 150 and 200ma respectively and not quite as low noise (but still 15.4µVRMS, 72dB PSRR).

its been a while since an actual +/- low noise regulator pair has been made as a pair and in the same package with similar specs, now theres 2! not breadboard friendly at all though

Last edited by qusp; 1st February 2013 at 01:26 PM.
  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 09:58 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