Does 0404 DSP resample 44.1Khz->48Khz?

[Glassman]

DSP itself can be stuck at 48kHz, that's no problem really, it can compute a few samples, then rest for a while and compute another and so on.. but then you need something that will take them, put them in order and output at continuos 44.1 and that's exactly the FPGA's job.. that's how I think it's done, the only logical explanation as to why Audigy has to resample while E-MU not, both using the same 10k2.. the difference is in the FPGA missing on Audigy and thus no way to do that trick, so resampling prior to processing is necessary..

 

[gaboo]

Quote:

Originally Posted by Glassman DSP itself can be stuck at 48kHz, that's no problem really, it can compute a few samples, then rest for a while and compute another and so on.. but then you need something that will take them, put them in order and output at continuos 44.1 and that's exactly the FPGA's job.. that's how I think it's done, the only logical explanation as to why Audigy has to resample while E-MU not, both using the same 10k2.. the difference is in the FPGA missing on Audigy and thus no way to do that trick, so resampling prior to processing is necessary..

I'm not sure you can use the DSP that way, it's not an asynchronous chip.
More likely the one clock can be set to 44.1Khz.

 

[maarek99]

Gaboo:

I don't remember the link but there were huge discussions about the 0404 around the net before it came and people were afraid of resampling (as in Creative).

 

[Glassman]

look at 1010, there's more than those two oscillators, there's a 48 crystal near the 10k2.. I think it's there solely to run the 10k2.. at 48..
also look at that ICS chip, from what I know, they make PLLs..

 

[gaboo]

Quote:

Originally Posted by maarek99 Gaboo: I don't remember the link but there were huge discussions about the 0404 around the net before it came and people were afraid of resampling (as in Creative).

There were discussions on RMAA forum about the 1212m/1820m when they came out. ICHi said that those don't resample.

 

[Lilac_Wine]

Does the 0404 use a discrete DSP chip? FPGAs are taking over more and more DSP functionality and tend to do it more efficiently.

I am sure that the Spartan can output a clock from its DLL. The family supports LVDS and other I/Os that are source synchronous.

My best guess is that the system clock is fed into the FPGA and clock manipulation as well as DSP functions are done on the chip. If it has a discrete DSP chip or PLL than those functions are obviously handled outside the FPGA.

As far as the FPGA reordering bytes, that seems unlikely. If there is an external DSP, that chip is not sending bytes out in a random order. It would be feeding them out in basically the same order as the stream it was receiving them in.

 

[Lilac_Wine]

After a bit of research, it does appear that at least some E-MU cards use a discrete DSP. My guess is the Spartan is not fast enough to handle all of the DSP functions – or DSP engineers are just used to using discrete chips, but that is another matter.

Still have not figured out if the 0404 has a discrete chip.

 

[Glassman]

they all use the same, years old E-MU 10k2 DSP with all of it's limitations.. the reason why they probably still use it is only cost - they must have them virtually for free since they're taken from old stock of Audigy chips.. the Spartan used there is the smallest of the series, definitely not used for any DSP, just signal and clock routing..

by arranging I mean buffering and outputting at constant rate, because the DSP only works at 48, but what does it means for the calculations themselves - nothing, they just run faster than it's needed, so I think it's being computed by a smaller chunks and rearranged - buffered - in the FPGA..

 

[gaboo]

Quote:

Originally Posted by Glassman they all use the same, years old E-MU 10k2 DSP with all of it's limitations.. the reason why they probably still use it is only cost - they must have them virtually for free since they're taken from old stock of Audigy chips.. the Spartan used there is the smallest of the series, definitely not used for any DSP, just signal and clock routing.. by arranging I mean buffering and outputting at constant rate, because the DSP only works at 48, but what does it means for the calculations themselves - nothing, they just run faster than it's needed, so I think it's being computed by a smaller chunks and rearranged - buffered - in the FPGA..

Glassman, the DSP is not clock agnostic. You cannot use as you propose it and get meaningful results from it, it's not a CPU! Your proposal won't work for effects where there is timing involved, e.g. reverb, auto-wah, flanger. You cannot fool the DSP to the work at a different frequency. There are only two possibilities: it works at 48Khz and resamples, or it works at 44.1Khz as well.

 

[gaboo]

A DSP is typically composed of two processors: a core processor, and an I/O processor. In addition, you usually have some internal RAM. To be useful a DSP core processor works at much higher frequency than the I/O sampling rate. Many DSP algorithms work in the frequency domain. These require frame-by-frame by frame operation, where the core waits for a group of samples, processes them, then writes out a group of samples. Out means to the on-chip memory. In order to be useful, a DSP program must finish in real time before the I/O processor needs to output the next sample. So, a DSP program takes less time to execute than it takes the I/O processor to output a sample. The DSP program receives data in real time too. Depending on frame-by-frame or sample-by-sample mode, the program is interrupt triggered when new data is available. The I/O processor has its own clocks for input and output ports. They can be derived from the core clock or not. It depends on the DSP.

Despite this asynchronous model, the input sampling rate of the I/O processor is very much relevant for some programs that run the core processor. Consider a simple program that adds a reverb. It needs to store some samples, the add them to the output them with some delay. The number of samples you need to wait depends on the sampling rate. So the input sampling rate is a parameter for the DSP program. In order to implement your proposal, you'd need to write a very different program, one that know that every 39/480 input samples must be ignored. The DSP programmers would simply frag the hardware guy that dares ask something like this.

The core clock on modern DSPs is the hundreds of MHz. E.g. this AD SHARC DSP. The I/O processor on that chip can set the serial ports frequencies using the internal clock, or can accept external clock.

So, what I think of the 1010 board. The "24" clock next to 10K2 is probably 24Mhz, and used through a multiplier to drive the 10K2 core clock in the 100-200Mhz range (rough guess based on the 1000MIPS number I remember the 10K1 claimed). The two smaller clocks to right of it are the I/O clocks. They don't seem to go directly to the 10K2, instead they go to the FPGA which, depending on the sampling rate, selects the right one, applies a divider/multiplier if necessary, and send it to the 10K2 I/O processor clock input pin.

I PMed our local DSP guru (jefemeister) to take a look at my reverse engineering attempt...

 

[gaboo]

Using lan's pic for analysis. There seems to be only one clock U9 on the right side of the board. The core clock vias for the 10K2 don't go through the top layer, so we have less info to speculate how this card works. It seems that the single clock source is used to drive both the core clock and the I/O clock on the 10K2. I can't tell from the picture if it is a normal CO, or something programmable.

Anyway, I don't think they can get away with chaning the core clock on the E-DSP when switching 44.1 <-> 48KHz; there may be other issues doing that. What I think is most likely to happen is that the MHz range U9 clock is divided differently by the FPGA for 44.1 and 48Khz.

In either case, the I/O clock for the 10K2 is very, very likely to be set to the right frequency depending on the sampling rate through the FPGA, so no resampling is required. There's still the question of what this circuit does to jitter. But there are two many unkowns to even speculate. Someone would have to measure it.

For the 1010 cards, the numbers reported by ICHi on the E-MU forum were ~500-600ps.

Strange enough IIRC lan reported better sound out of 0404 digital output than out of 1820M...

 

[lan]

Quote:

Originally Posted by gaboo Strange enough IIRC lan reported better sound out of 0404 digital output than out of 1820M...

That is strange. Do you have a link to this?

Did I say out of 1820m dock or 1010 card.

 

[gaboo]

On both 1010 and 0404, the FPGA is connected to both sides of an ICS525R-02.

This is a user configurable clock divider/multiplier, up to 250Mhz, and has two clock outputs. It seems the FPGA controls the clock output rate by grounding or floating the control pins. On a quick caclutation you can divide up to 1270 or something like that, and has very fine grained divisions. So it can be used to derive both the 48Khz and 44.1Khz clocks easily from a Mhz clock.

 

[gaboo]

Quote:

Originally Posted by lan That is strange. Do you have a link to this? Did I say out of 1820m dock or 1010 card.

See, your constant 0404 > rest-of-EMUs propaganda really worked on me.

I'm totally confuzzled now.

 

[lan]

Quote:

Originally Posted by gaboo See, your constant 0404 > rest-of-EMUs propaganda really worked on me. I'm totally confuzzled now.

my friend, you need to take a break

you're like constantly researching or something

let me go find what I said.