High Quality Audio. Prop Dac or other DAC?
T Chap
Posts: 4,223
I am designing a board that will have an SD card and RTC for data logging and other expansion uses, this board has a dedicated Prop so that the main board Prop doesn't have to get squeezed to fit the new requirements. The Main board will send opcodes via a short cable to the new board.
I have spent some time looking at the OBEX and searching the forum for DAC Audio.
http://forums.parallax.com/showthread.php/132857-WAV-File-Magic
From what I can tell Kye and jonny mac have spent a lot of time working on high quality output.
I don't have a board with an SD card today to start testing the objects above. I was wondering if anyone has any opinions on the existing WAV file magic or Stereo Duty object mentioned by Jonny Mac in comparison to a 16bit DAC. The next question would be can the Prop 1 even handle speeds required to read a stereo 16 bit wav file and transfer the data to either 2 DAC's or a dual DAC. The board will incorporate 2 THATcorp 4315 VCA's on the output of the DAC section for gain control,(single supply version that works at 5V), so I am not concerned about handling volume in the audio data itself as the DAC output will be turned off when the audio is not playing. http://www.thatcorp.com/datashts/THAT_4315_Datasheet.pdf
The VCA is to be used to quickly/elegantly fade out the audio if the file to requested to stop immediately, which is very useful in voice prompt applications where a user may make a menu selection while a prompt is playing. The DAC will feed both a built in amplifier to drive speakers approx 2w, and will also provide line outputs for the user to connect external amps/speakers. It would be very nice to simultaneously allow playback to SPDIF using that object, maybe there is a way to closely sync the local DAC with a cog running the SPDIF object.
I currently am using a Vinculum>VS1033 with mp3's, but with the new board the goal is to get away from the Vinculum ( essentially a modified Vmusic2 schematic). The output of the 1033 is very nice, but the Vinculum has to be programmed and both of the IC's are very fine pitch and somewhere a hassle.
Any thoughts on the best DAC quality with the goal of 16 bits stereo?
I have spent some time looking at the OBEX and searching the forum for DAC Audio.
http://forums.parallax.com/showthread.php/132857-WAV-File-Magic
From what I can tell Kye and jonny mac have spent a lot of time working on high quality output.
I don't have a board with an SD card today to start testing the objects above. I was wondering if anyone has any opinions on the existing WAV file magic or Stereo Duty object mentioned by Jonny Mac in comparison to a 16bit DAC. The next question would be can the Prop 1 even handle speeds required to read a stereo 16 bit wav file and transfer the data to either 2 DAC's or a dual DAC. The board will incorporate 2 THATcorp 4315 VCA's on the output of the DAC section for gain control,(single supply version that works at 5V), so I am not concerned about handling volume in the audio data itself as the DAC output will be turned off when the audio is not playing. http://www.thatcorp.com/datashts/THAT_4315_Datasheet.pdf
The VCA is to be used to quickly/elegantly fade out the audio if the file to requested to stop immediately, which is very useful in voice prompt applications where a user may make a menu selection while a prompt is playing. The DAC will feed both a built in amplifier to drive speakers approx 2w, and will also provide line outputs for the user to connect external amps/speakers. It would be very nice to simultaneously allow playback to SPDIF using that object, maybe there is a way to closely sync the local DAC with a cog running the SPDIF object.
I currently am using a Vinculum>VS1033 with mp3's, but with the new board the goal is to get away from the Vinculum ( essentially a modified Vmusic2 schematic). The output of the 1033 is very nice, but the Vinculum has to be programmed and both of the IC's are very fine pitch and somewhere a hassle.
Any thoughts on the best DAC quality with the goal of 16 bits stereo?
Comments
' Sets AD5322 dac channel ' -- expects 16-bit value ' -- bit15 holds channel (0 for volume, 1 for output) ' -- bits 14..12 should be clear ' -- bits 11..0 hold output value setdac shl aout, #16 ' shift bit15 to bit31 (MSB) mov tmp1, #16 ' shift 16 bits andn outa, smask ' sync low spiloop rcl aout, #1 wc ' move bit (MSB) to C muxc outa, dmask ' move C to DIN pin andn outa, cmask ' clock low or outa, cmask ' clock high djnz tmp1, #spiloop ' more bits? or outa, smask ' sync high setdac_ret retThe biggest headache of the project was soldering the uSOIC package to an adapter I could test the code on a PPDB. I managed it, though, and the client said it worked perfectly on their end.
This devices uses a single SPI interface, so that Channel A and B are address in the data stream, with a command to update either channel or both.
http://www.analog.com/static/imported-files/data_sheets/AD5025_5045_5065.pdf
This is a TSSOP package with pin spacing of .65m which is not a big deal but I always prefer something larger, 1.27m etc.
Versus the AD1866 in SOIC, which looks even better for audio.
www.analog.com/static/imported-files/data_sheets/AD1866.pdf
This device has separate data inputs for left and right, sharing the same clock:
Without having a lot of PASM knowledge, it is not easy to know if there is a problem of time reading the stereo 16 bit data off the card and writing it, so I wouldn't know if there were a preference for the method of input. In one of the example schematics shown in the datasheet, the LR and LL latches are shown inverted from the device sending the data, so that this would indicate that they are sending the left channel and right channel separately since the falling edge of the LL and LR are what cause the 16 bits to shift into the DAC. In this case, I don't see any real difference in timing from one device to the other, as the data is being clocked in separately and not at the same time. Maybe there could be a method to send the data to the DAC at the same time as a time saving benefit? If a single loop can set the left and right data pins, toggle the clock pin, then I don't see why you wouldn't do both data outputs in the same loop in PASM.
The chip is designed to work that way and is quite straightforward to implement. Instead of one data pin, you have one for each channel. You have a few more lines in the output loop, but it's not any more complicated that what I showed above.
However this approach needs a master clock that's a high multiple of the sampling frequency, and
driving these I2S DACs/ADCs is best done by clocking the Prop at a similar multiple.
I've used 12.288MHz MCLK before, Prop goes at 8 times this and a cog is dedicated to driving the
LRCLK, BCLK and data lines.
Can dig out the code if it helps. Built a DDS audio sinewave generator using CORDIC to generate
24 bit samples at 48KSPS for this chip, it works from 3.3V and generates DC-free 2.0V rms (has
own internal -3.3V rail generator). It claims -106dB S/N
@T_Chap: Hopefully, the code you're using is speed agnostic, that is, it adjusts itself to the speed and isn't locked to a specific frequency. Of course, many objects will require a minimum speed, but I can't think of a reason for an upper limit. 12.288 x 8 = 98.3MHz; you'd get a little more performance out of you code that normally runs at 80.
On some audio forums, this DAC is referred to as the better option for audio than the WM8524, it is a similat I2S device with charge pump, 24bit.
Here is a comparable TI DAC
http://www.ti.com/lit/ds/symlink/pcm5102.pdf
Has anyone used/mentioned the Nuvoton NAU8402 ?
https://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=10324f97-b6f3-4a58-bc76-d51f14544b38
Also a Stereo DAC, with charge pump for 2Vrms analog output capability., no caps.
I see Digikey have NAU8402 in stock, for 100 : $1.0535
Not sure if this can be used as a DC DAC ?
256fs or greater is recommend ed for 32kHz to 96kHz sampling.
For 44.1k does this suggest that the Prop will need to produce a master clock of 44100 * 256 = 11,289,600? This should be easy to handle with either the 5m or 12.288 crystal.
There are solutions:
- use 11.2896 MHz crystal for the Propeller and DAC
- use DAC chip with internal oscillator, for example WM8731
I will add this TI clock source, so is there a preferred Prop crystal with the master clock now being handled outside the Prop.
Generated Audio System Clock (PLL1707): fS= 32, 44.1, 48, 64, 88.2,96 kHz)
http://www.ti.com/lit/ds/symlink/pll1707.pdf
EDIT it looks like the 1708 has greater flexibility of control using serial config.
There is also the SI5351A-B-GT, lower cost and smaller, with more frequency control, over i2c, but a little more complex to drive.
ES9023 DAC
PLL1708 Clock
SD Card
S-35390A RTC
Prop
FT232RL
The only thing I am looking at is if I want to put a buffer on the clock output into the the DAC. Not sure if this is really needed on a trace of less than 1". There are several clock outputs, I was thinking of selecting the clock line by included an 0603R in the path.
That reduces the jitter, less clear by how much exactly - so measuring could be a good idea.
Also promising could be CSTCR5M00G53Z-R0, with the Prop C's this might pull down to the 4.992000MHz needed. -0.160%
(my feeling is the Prop C's will over-pull, past the ideal -0.160%)
or, if 64MHz is ok, Mouser have CSTCR4M00G15C99R0 which is tighter spec, and the lower F will pull less with the lowest Prop C setting. I make jf=1.23MHz lowest jitter solution for (4Mz-0.160%)*16 fPLL_ref = 6.153846153MHz in both cases.
While you are experimenting, there is a xtal/pll solution that divides by 13 for 47 of 48 times and /14 for 1 of 48 => 13*47+14 = 625 but this will have a jitter-spur at 128kHz in the PLL, and the PLL will not filter that as well - but it may be acceptable.
http://forums.parallax.com/showthread.php/150602-New-WAV-player-(V2)?highlight=wave+player+v2
It works really good.
ES9023 DAC
SD Card
S-35390A RTC
Prop
FT232RL
ICS83054I Clock buffer/ 4in 1 out multiplexer Prop will select the clock line
2 TDA7052A 1 watt amplifier for local speakers
Burr Brown OPA2xxxx for output filter options
PLL1708 Multi clock generator
Audio Side regulators (low noise) MIC5205-3.6 MIC5205-3.3
Here's the code of my audio oscillator (complicated by the 7-segment display driver etc), but the
driver's in WM8524_DAC.spin:
I've also interfaced to other I2S devices, ADCs too.
Can someone explain in simple english the process of reading the SD card audio data and passing that data to the DAC engine? Does the FAT engine need to grab one sample at a time of the left and right 24bits, and the DAC engine reads it from main memory using rdlong left and rdlong right, update the DAC and repeat? I don't get the part of how the DAC engine syncs to the FAT engine reading the data so that the DAC engine does not repeat the same/previous data if the SD card stops or runs out of data. I am sure that after studying Kye's object this will start to make sense, but it would be nice to know what to look out for.
In Mark's DAC engine, I see the FRQB is set for the bitclock out and each write the DAC is sync'd to the bitclock:
However, in his code there is no SD card being read as the cordic engine is creating the DAC values.
Normally you would create a FIFO style buffer, where SD write-to-buffer and DAC server read-from-buffer. Provided the SD fetch can average faster than DAC writes (fixed rate), and without pauses longer than the buffer size, then you can have smooth data supply. If SDwritePtr == DACreadPtr you are Full, and wait until SDwritePtr <> DACreadPtr
I've attached code from one of my Nuts & Volts columns that uses this. My audio engine plays only 16-bit files (mono or stereo).
_clkmode = xtal1+pll16x _clkfreq = 80_000_000 _SD_DO = 0 _SD_CLK = 1 _SD_DI = 2 _SD_CS = 3 _SD_WP = -1 ' -1 ifnot installed. _SD_CD = -1 ' -1 ifnot installed. VAR long cog long buf[512] long bufnum obj fat : "kyefat_lfn" pub demo | i fat.FATEngineStart(_SD_DO, _SD_CLK, _SD_DI, _SD_CS, _SD_WP, _SD_CD, -1, -1, -1) i:=fat.mountpartition(0) start(11,10) 'buf:=sample.getbuf repeat fat.openfile(string("wav.wav"),"R") repeat repeat until bufnum>1024 i:=fat.readdata(@buf,1024) repeat until bufnum<1024 i:=fat.readdata(@buf+1024,1024) until i<>1024 pub getbuf return @buf pub getbufnum return bufnum PUB start(left, right) longfill(@buf,0,512) bufptr:=@buf stop leftcounter := ((left & $1F) + constant(%00110 << 26)) rightcounter := ((right & $1F) + constant(%00110 << 26)) outputmask := |<left | |<right cog:=1+cognew(@init, @bufnum) return cog PUB stop if cog>0 cogstop(cog-1) cog := 0 DAT org 0 init mov ctra,leftcounter mov ctrb,rightcounter mov dira,outputmask mov bufptr2,par mov time,cnt add time,delay loop mov ptr,bufptr add ptr,bufcnt rdword lsample,ptr shl lsample,#16 add ptr, #2 rdword rsample,ptr sar lsample,#16 shl rsample,#16 sar rsample,#16 add bufcnt,#4 and bufcnt,bufmask mov over,#6 wrlong bufcnt,bufptr2 p2 add i1l,lsample add i2l,i1l mov topl,i2l sar topl,#8 mov fbl,topl shl fbl,#8 sub i1l,fbl sub i2l,fbl add i1r,rsample add i2r,i1r mov topr,i2r sar topr,#8 mov fbr,topr shl fbr,#8 sub i1r,fbr sub i2r,fbr maxs topr, maxval mins topr, minval add topr, #$80 and topr, #$FF maxs topl, maxval mins topl, minval add topl, #$80 and topl, #$FF shl topr, #24 shl topl, #24 or topl,a or topr,a waitcnt time, #46 mov frqa, a8000 mov frqb, a8000 waitcnt time, #256 mov frqa, topr ' Output. mov frqb, topl ' Output. djnz over,#p2 jmp #loop leftcounter long 0 rightcounter long 0 outputmask long 0 time long 0 delay long 256 lsample long 0 rsample long 0 bufmask long %0000_0000_0000_0000_0000_0111_1111_1111 ptr long 0 temp long 0 bufptr long 0 bufcnt long 0 bufptr2 long 0 over long 0 topl long 0 topr long 0 fbl long 0 fbr long 0 i1r long 0 i1l long 0 i2l long 0 i2r long 0 maxval long 127 minval long -127 a8000 long $80FF_FFFF a long %0000_0000_1111_1111_1111_1111_11111111 fit 496Here is my driver - one of older version. You have a buffer and an counter. The Spin procedure is watching a counter and loads a chunk of data when needed. The ASM driver increases a counter every time it is getting data from it. The AND instruction causes it to loop endlessly within a bufffer memory.
I am adding a Prop dac for testing and comparing some of the various drivers. I have seen your guys discussing several r/c values. I'd like to hear what methods of r/c plus any filtering you might be doing for best results. I added a +/-3v supply and bipolar op amp output that can be inserted and allow for some gain.
Edit. 768*44100 = 33,868,800. Not doable assuming 4 prop clocks per pulse required. 256 or 384 is doable I believe
There could be a couple of choices here.
i) Clock the Prop in direct mode (no prop PLL) from the external PLL, and run at that MHz. This is going to be slower, and vary with rate, but may still be ok. It does force you to use an external PLL.
ii) Feed the external PLL into a COUNTER as POSEDGE mode, and now CTR incs at a sampled Fi, but is checked at fsys,
The master CLK is from the external PLL and the small data-edge jitter will likely be quite ok, as there will be a small pipeline effect, and sampling variation should be 12.5ns
I think the Prop is good to 50% of the fSYS speed, due to the pin-sampling, at 50% signal duty cycle.
If the ExtPLL has 50% duty, 33.8MHz should give about 4.525ns of skew margin on 40MHz sample.
You could check this with a ExtPLL-> COUNTER -> WAIT -> PinChange, and time the delays & jitter on PinChange, from the external edge.
The goal is to initially play back 16bit stereo wave files from SD. After that gets up and running I want to have the option for 24bits, the DAC wants padded values if less than 24 bits is sent. I will send out the board to someone ( if that can be arranged ) when I have one ready, but without some method to test the DAC, I am not sure how to know if the board works on the clock and DAC section.
In case someone is interested, here is the plan:
A PLL1708 clock will generate a master clock which is output on any of 4 outputs, the clock itself will need an SPI driver to configure the clock and outputs.
The master clock pins SCK00 and SCK01 feed a highspeed OR gate, that feeds the DAC. The clock outputs SCK02 and SCK03 feed an OR gate that goes back to the Prop in case that method warrants testing, else the PASM will generate the 44.1k timing for data output.
The board has configurable sections, but those are not important at the moment until some audio will play, then I can sort out how well the audio section worked out.
There are other simple details but that can wait.
The board is multi purpose, RTC and data logging, it will receive serial commands from a master controller board with simple opcodes to tell it what to do. I did include 3 buttons that can be used just for testing, then I will write the SPIN code to parse incoming instructions. I can't use a method that requires the files to be stripped of anything. I need a client to be able to load on a file based on some naming criteria only, then the file can be selected by a number from the main board. IE 5000.wav 5001.wav etc.
I did include a Prop DAC output and will want to compare both options on the board.
Sorry, can't seem to get a non blurry schem to show up, the site is compressing to much.
I am wondering how is the PASM code going to sync up with the I2S DAC?
Is the master clock from the PLL going to a Prop pin and then through counters to generate the Left/Right clock (LRCLK) and bit clock (BCLK) that the PASM code will monitor to know when to send out data bits?
If so, then maybe overclocking the Prop, maybe 100MHz, to reduce sampling jitters caused from the PASM waiting for a LRCLK edges.
I have done this stuff in Verilog RTL which had no jitter problems since the flops were synced to the bit clock.
Sound like much fun.
cheers,
rich