24 channels USB to I2S interface (with Source codes, ASIO/VHDL/Schematic) - Page 2 - 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 15th November 2011, 09:36 PM   #11
diyAudio Member
 
Join Date: Nov 2006
dean: if you are talking about PC software clock / DAC clock buffering issue, This design is free from that. Only one clock drives everything.

(1) at the end of VHDL, you can see re-clocker. of course you can implement as you like, including power, isolation and buffers, on the outside of FPGA. (this is IL711 / 74HCxxx etc, DIP devices issue)
(2) see VHDL, the state machines run with "Full Flag" and "Empty Flag", and frame sync.
PC to FTDI: only processed when FTDI buffer is not full.
FTDI to FIFO: only processed when FTDI has data and FIFO is not Full.
FIFO to FPGA: only processed when FIFO is not empty and next frame requested.
FPGA to I2S output: MCLK (256fs) drives every bit.
(3) see C code, it adds 7fffff800000 as frame header. and in VHDL, you can see 7f->ff->ff->80->00->00 tracer state machine. If FPGA can not sync, all registers are cleared to 0x000000.
(4) FPGA module has flash memory. so power-on reset will cause reprogramming.
(5) "jitter" buffered to the FIFO? FIFO only has 00-ff data as result of writing operation. there are no information that "this D0 was recorded 15 ps earlier than next D1" all data lines are fixed when write pulse goes 0->1.
  Reply With Quote
Old 15th November 2011, 10:27 PM   #12
deandob is offline deandob  Australia
diyAudio Member
 
Join Date: Oct 2002
Location: Brisbane, Australia
Thanks Koon for answers.

How do you avoid the state machine from recognizing 7fffff800000 in the audio data stream? I assume you wait for the header and don't look for the header in the stream until you have fully received a frame.

Any reason for this particular bit sequence as a header?

I assume there is no facility for retries, so if a sample is corrupted there is nothing that can done but pass the distortion through to the DAC. You could implement a checksum for each frame and implement a resend? Chance of corruption is pretty low though.

Sorry my last question was about PC isolation, not jitter. I think its pretty clear that putting isolators between each of the FTDI 245 FIFO outputs will be a good method, and with a baud rate of 4Mbps (24 bits x 192Khz for 8 channels) for the 245 FIFO parallel output will be easy for an isolator and allow us to completely separate the FTDI (powered by the USB port) from the rest of the digital logic. Another reason for keeping the external FIFO.

How do you change sample rates? If the PC application changes sample rates then you need some way to adjust the clock rate of the FPGA else you get buffer under/overruns. I assume you could implement in your frame a couple of bits to indicate the frame rate and have the PFGA adjust to suit.

Have you had problems with latency using the D2XX driver? In an earlier project I implemented a RS485 protocol using D2XX and used the DTS/RTS lines as signalling between the MCU and the PC, yet I found I would occassionally see 10 - 30msec latency delays (at random) which caused network errors with my solution (but still OK as protocol recovered) and investigations pretty much pointed to the D2XX drivers. So I was wondering if you have found any irregularities with using the D2XX drivers?

Also, you mentioned in your original post "FIFO can be changed to Cypress or faster one, if you want synchronous speed". Is it that your FIFO cannot handle high sample rates?

Last edited by deandob; 15th November 2011 at 10:36 PM.
  Reply With Quote
Old 15th November 2011, 11:23 PM   #13
diyAudio Member
 
Join Date: Nov 2006
Hi Dean,
7fffff800000 : this is checked only at the starting of the frame. in the 24ch x 3 = 72 bytes sequence, there are no checking (see VHDL). so State machine always waiting for the header, then check, if OK, process 72 bytes data.

7fffff800000 means +1 (full top height) and -1 (bottom) of PCM. if your wav always contains this pattern, that is not music, should be full volume square wave.
There are another method that 8bit/7bit encoding. But I just want PCM data transfer, not want to implement strict data communication protocol.

retry: when corrupted, the data is cleared to 0x000000. DAC will receive 0.
resending: when FPGA find corrupted frame, then.. send NAK to PC, clear the FIFO, and wait for PC? it will cause some msec silence. I think discarding 1 sample (1/44100) is better.

Isolation point: also it's your free selection where to isolate, .. but including FPGA into DAC area, or Clock / FPGA in same PSU area?

Sample rate: I'm simply thinking to add mechanical switch to change clocks.
you can modify the VHDL/C to include (a) Clock selection byte (b) Clock selecter / buffer.

D2XX: I don't expect much, only writing 512 x 78 = 39936 bytes per host cycle.

FIFO: I had IDT72V so I used it, and it can work up to 15MB/sec > 96k/24bit/24ch.
if someone wants to implement 384k/24bit/24ch, this is 27MB/sec.
  Reply With Quote
Old 16th November 2011, 03:22 PM   #14
diyAudio Member
 
Join Date: Nov 2006
Attachment is the source code for ASIO client.
This program takes 1 argument as WAV file name (44.1 16 or 24),
read whole data into memory, then start ASIO.
with ASIO SDK I can trace this client - ASIO class - my driver, but inside ASIO is very confusing
Attached Files
File Type: txt AsioClientTest.cpp.txt (6.9 KB, 59 views)
  Reply With Quote
Old 16th November 2011, 08:39 PM   #15
diyAudio Member
 
Join Date: Nov 2006
Dean,
If you want to make "resending" protocol,
(1) PC side have to read ACK/NAK after each communication
(2) you will need USB2.0 HighSpeed MCU, with enough RAM, about 200KB? for 50ms headroom.
(3) MCU check each frame from PC, if OK send ACK and store, if corrupted send NAK and discard.
(4) PC will send again if NAK. (3)-(4) cycle can not exceed the headroom at (2).
This is too much, than I want.
I just need corruption should be recovered within some frames, or DAC will receive all 0x00.
  Reply With Quote
Old 16th November 2011, 09:03 PM   #16
deandob is offline deandob  Australia
diyAudio Member
 
Join Date: Oct 2002
Location: Brisbane, Australia
Koon, are you having trouble with ASIO? A more flexible alternative to ASIO is to use the MSVAD virtual audio driver, which installs as a soundcard and the Windows DDK sample provides copyFrom & copyTo functions to get/put data into the driver buffer. This way any windows application can be used, not just ASIO clients.

Also, can you talk a little more about how you avoid buffer overruns, I assume as you have posted you are sending the audio to the FTDI hardware at max speed which is much faster than the audio sample rate, so there has to be signalling back to the PC to stop writing to the FTDI buffer else the FIFO will quickly overrun. I can't see that in your PC or VHD code. Previously I used the RTS/CTS FTDI functions for buffer signalling but I found the latency on these lines unreliable with the FTDI USB 1.0 solution I used.

I agree that resending is not needed, and a MCU will not be fast enough for this solution. Thinking about how to handle corrupted packets, the FTDI protocol layers should have mechanisms like checksums and methods to handle corrupted packets, so if we assume the FTDI bits are error free, and we don't have any logic errors and a decent PCB trace layout we can assume the data will be error free. You mention that if you see a sync error you output all 0's, wouldn't it be better to repeat the previous sample, that would be less obvious, assuming the error doesn't last more than a couple of frames?

How does it sound? Do you get any dropouts?
  Reply With Quote
Old 16th November 2011, 09:34 PM   #17
diyAudio Member
 
Join Date: Nov 2006
Hi Dean,
MSVAD: that is, DDK. ASIO is confusing but far better than DDK.
at 245 FIFO mode FTDI can not accept data when FIFO is full. so my programs just issue FT-W32_WriteFile() and waiting the data are consumed.

0 and hold_previous_value: if stopped with data 0x657834, your speaker will receive high voltage DC signal, continuously.

Sound is just bit perfect, free from buffering / SPDIF clock generator etc.
sync error: I'm watching frame sync error on debug pin out from FPGA but nothing happen.
  Reply With Quote
Old 16th November 2011, 09:44 PM   #18
deandob is offline deandob  Australia
diyAudio Member
 
Join Date: Oct 2002
Location: Brisbane, Australia
Yes, of course, any logic or system error putting any value other than 0 on the outputs for a period of time is bad.

I understand the D2XX buffer will block, that makes the PC side easy. So basically if the small FIFO on the FTDI chip is full the FTDI framework stops sending, and its up to the user to pull out the data from the FTDI FIFO when it is ready. Very simple.

I am going to order parts to start assembling a prototype. I'd like to use a FPGA with onboard SRAM for the FIFO and modify your code to implement onboard FIFO which should be simple. I need to learn VHD but looking at your code it looks pretty easy (I have Pic micro assembler experience, VHD looks easier!). I will look to implement automatic clock switching for different sample rates.

Do you have any pointers to get started on DIY FPGA? I can see they can be easily programmed through a JTAG port, no need for the expensive DLP-HS-FPGA2 module. I need to find a PLCC FPGA with sufficient SRAM.
  Reply With Quote
Old 16th November 2011, 10:29 PM   #19
diyAudio Member
 
Join Date: Nov 2006
Please try from learning VHDL as software, and simulation. that's free.
Cheap FPGA will be.. search "Xilinx" "Altera" "Lattice" etc on eBay. you can find modules, bare chips, programmers.
Do It Yourself about applications of FPGA shows simple FPGA examples.
  Reply With Quote
Old 17th November 2011, 02:28 AM   #20
deandob is offline deandob  Australia
diyAudio Member
 
Join Date: Oct 2002
Location: Brisbane, Australia
Thank you Koon, you have been very helpful, and because of your insights (and a little help from FTDI ) it looks like a hi-rez async multichannel USB DAC is within relatively easy reach (and much cheaper than similar solutions)!

I'll start working on ordering parts, putting together a schematic and ordering PCBs (I have 2 to make). I'd be happy to share any enhancements and tweaks.
  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
Introducing miniStreamer: Native 24/96 USB to I2S / SPDIF interface minidsp miniDSP 39 6th January 2014 12:00 AM
Ultimate USB to I2S interface sampler Digital Source 206 30th January 2012 04:45 PM
Edel USB to I2S/SPDIF interface danny_66 Digital Source 0 27th July 2011 08:42 PM
Is it possible to develop a ASIO driver for PCM2900 based USB Audio interface? cxhawk Digital Source 7 3rd December 2010 03:30 PM
interface I2S with USB mermoz Digital Source 0 21st February 2003 11:34 AM


New To Site? Need Help?

All times are GMT. The time now is 01:38 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