USB to multichannel PCM

[dpenev]

Hi Guys,

I need to implement USB2.0 to 32 channel 2048KHz PCM (d_in, d_out, clock, frame_sync) bus.
I will need just a few channels, not all of the 32 available.
USB port will be driven by a Linux embedded PC. 

I was thinking about using USB<->FT2232H(SPI) <->(FPGA)<->PCM
I am after the simplest solution possible .
If a chip is available I will be happy to use it.
Or probably some project implementing something like this?

Any ideas please let me know.
Dimitar     

[dpenev]

Thank you Blueskull for your remark.

Yesterday I fount independently the XMOS solution.
They seems don't support  PCM in slave mode out of the box but probably will be an easy hack.
I got an impression that the XMOS USB audio class is already supported in Linux.
Can you elaborate on the "NDA and firmware"?   
 
>or hub+multiple 2ch/4ch USB-PCM converter ICs
Can you please elaborate on this one.
Which USB-PCM converter ICs you have in mind?

[NiHaoMike]

You can use a FX2 for USB 2.0. Look up "fx2pipe" for example code.

[SiliconWizard]

You're not saying if you want your device to act as an USB audio device, or if accessing it in bulk mode is OK.

In the former case, I'd also suggest using a XMOS-based solution, or a specialized IC. Implementing USB audio on some MCU is never a picnic. There are some example projects out there, but that's never as pain-free as it looks. IMHO. Also, in this case, FTDI devices can't be used, as they don't support the USB audio class.

Now if bulk mode is OK, you have quite a few options there. FTDI devices, MCUs with an USB core, ... you'll just have to make sure your throughput (and maybe latency, if that matters) requirements can be met.

I don't see the point of using SPI between the FPGA and FTDI device (if you go that route). For a few more data lines, just use a parallel mode, which will give you better throughput and will additionally be easier to implement.

[dpenev]

Thank you NiHaoMike, I will take "fx2pipe" a look

SiliconWizard I will try to explain a bit more.
At the moment I have a telephony system based on Blackfin CPU. Blackfin has a SPORT interface which can read the multichannel PCM bus.
I have developed a custom DAHDI driver which is hooked on the data steam coming from this external multichannel PCM bus.
This multichannel PCM bus is acting as a clock source for the DAHDI driver.
Now I consider migrating the system to a powerful embedded i7 single board computer
and I consider interfacing the PCM bus with an USB.

I don't have much experience with USB but in Linux kernel I need to have an interrupt if a given buffer of data (from the PCM) has arrived.
That is all I need.

Any insight are welcome.   

[SiliconWizard]

From what I gather, you should be able to use USB bulk transfers... as long as your throughput and latency requirements are met. Can you give us more details about that? What's the max throughput? What's your min expected latency?

[dpenev]

Thanks SiliconWizard

The throughput is actually modest.
In the initial version of the system I will have only 1 time slot of the PCM bus loaded ,
so I have 8KBytes/s transmit and same receive,
assuming the data are mu-law encoded.
If linear encoded I will have 16KBytes/s

If the latency in the USB-PCM is a few ms I will be OK.
If this audio channel is opened data will arrive from PCM bus regularly (with nanoseconds accuracy)
 
     

[Scrts]

I would probably look into USB->I2S or USB->S/PDIF then do I2S/S/PDIF -> PCM.
So for USB there are very well supported devices like PCM29xx series (PCM2903 or PCM2906) then use something like PCM9211 for I2S to PCM and it seems to support multi-channel.

[asmi]

Question - does it really have to be USB? As far as I know, Intel PCH's support all kinds of digital audio outputs, including multiple I2S/PCM channels, so your embedded board can output them directly.

[SiliconWizard]

Question - does it really have to be USB? As far as I know, Intel PCH's support all kinds of digital audio outputs, including multiple I2S/PCM channels, so your embedded board can output them directly.

That's a good point. Of course we need to know if the OP's motherboard has digital audio output(s). But if so, then definitely I'd agree. And since they are using Linux as an OS, direct access to audio outputs should be relatively straightforward (thus, getting a bit-exact output), whereas on OSs such as Windows, it's not as easy as Windows has a lot of layers from its audio API to the driver and eventually output. And with some care, you can then actually send any arbitrary data through I2S or similar.

I2S is also easy to implement on FPGA, so I'd vote for that as well.

[asmi]

That's a good point. Of course we need to know if the OP's motherboard has digital audio output(s). But if so, then definitely I'd agree. And since they are using Linux as an OS, direct access to audio outputs should be relatively straightforward (thus, getting a bit-exact output), whereas on OSs such as Windows, it's not as easy as Windows has a lot of layers from its audio API to the driver and eventually output. And with some care, you can then actually send any arbitrary data through I2S or similar.

That's a popular myth. You can output bit-perfect audio in Windows with no problems if you set everything up properly. But OP said his board is running Linux, so this is a moot point.

Intel provides drivers for both Win and Linux, so there shouldn't be any issues on a software side, but you will have to make sure those digital audio channels are broken out on a board, and those connections are good enough for I2S speeds, which can reach into multiple 10's of MHz, so not very high compared to other things, but just high enough that SI might become a problem, especially if used in industrial or other high-EMI environments.