Does 0404 DSP resample 44.1Khz->48Khz?

[gaboo]

Quote:

Originally Posted by Glassman and do you think the first E-MU APS with 10k1 onboard couldn't lock on external clock sources?

And it didn't resample?

 

[Glassman]

maybe, but it had to lock on 44.1 incomming stream and work with it.. this all with just 48kHz fixed I/O..

 

[gaboo]

For the neophyte reading this, the latest debate between me & Glassman is not whether the 1010/0404 card as a whole resamples. It's about how (or if) EMU fixed the old 10K1 fixed 48KHz output.

The crux of this debate is whether EMU actually did implement a DSP with variable clock I/O, or whether they used some external glue to fix the problem (still w/o resampling).

It is indeed feasible that they could have added another layer of I/O to do 48->44.1. And yes, you can do this one way conversion, i.e. 48->44.1 w/o resampling. But the 48Khz, cannot be true 48Khz output, it would have to be 44.1Khz-padded-to-48Khz. This gimmick requires rewriting of all DSP algorithms to deal with this "padded" output mode. It is simply not sound engineering.

Second, for recording at 44.1KHz, you are SOL. You just can't do the inverse function (because your function is not inversable in realtime!). You'd have to resample somewhere, at least for the input. The "analogy" that Glassman tried to offer wrt. to the old E-MU APS product is simply flawed. That old 10K1-based APS did resample the input from anything in between 28-53Khz to the fixed internal 48Khz.

Finally, the last straw man argument is the "512x48 crystal next to the 10k2". This one is simply not an issue, as it drives the core processor of the DSP. There is no problem with it running faster that the I/O. In essence, the trick the Glassman proposes wrt to output, does happen, but inside the 10K2 DSP. All hard realtime systems work like that: output the result before the next deadline. If you want to guarantee 512 instructions executed per sample, you don't have to do exactly 512x times the work of the output. Anything above it works. So the core can be "overclocked" wrt. to the output processor when the latter works at 44.1Khz.

 

[gaboo]

This is what ICHi had to say about the "fixed 48Khz DSP" here, post #108:

***Come on guys, I have written this like 5 times already. The DSP is NOT, it is NOT sample rate locked. It is controlled by the clock subsystem and will move to whatever sample rate the system is currently set at. So if you set it to 44.1 it's running at 32 bits, 44.1, set it 48, it's running at 32 bits, 48 so on and so forth.

 

[Glassman]

that's a definite answer, thanks for posting this gaboo.. I'm glad to see my card can do these tricks natively

because that's also a proof that 88.2 and 176.4 samplerates are easily achievable the same way as 96/192 are.. I hope they got an xmas present for us

 

[gaboo]

Quote:

Originally Posted by Glassman that's a definite answer, thanks for posting this gaboo.. I'm glad to see my card can do these tricks natively because that's also a proof that 88.2 and 176.4 samplerates are easily achievable the same way as 96/192 are.. I hope they got an xmas present for us

Yeah, that probably just a matter of programming the FPGA to program the ISC chip with the right divisors. That's probably easier than what they had to do to make 192Khz available on the 0404. The hard part would be to remake the skin of the Patchmix app.

What I found more interesting in that thread is that ICHi mentioned twice the (remote) possibility of effects at > 48Khz. Unless they can overclock the I/O (extremely unlikely, they would have done it from the start), the solution would be to multiplex the data in two channels. This already happens for ADAT input/output at >48Khz anyway (S/MUX), so there is some support for muxing/demuxing.

E.g. at 96Khz, the DSP would have to output two samples per 48Khz clock beat, as separate channels, and the FPGA would have to serialize them as one 96Khz stream. This would basically require different and pretty complicated FX algorithms at > 48Khz... They would probably be able to offer less than half the "slots" this way at 96/88.2Khz, and 1/4 at 192/176.4 due the doubling or quadrupling of work before the deadline, mux/demux overhead, and more complicated DSP programs. And if they have a "true" 96/192Khz DSP in the pipeline they may see it as a threat to future new product sales.

 

[Glassman]

it already works as described, 96 and 192 are transfered as two or four 48 channels and muxed in the FPGA, the problem is when you have to do DSP over the signal, you need to know certain number of past and future samples to count with and that limits the effects to 48 only.. but if they discover a way how to split the computation between more DSP chains, they will be able to run effects at 96 and 192.. this however is not easy at all, you cant just demux and mux.. filter coeficients are would be the same, however one each DSP chain would have to know the results generated by others to count with..

making 0404 support 192 was easier than preventing it from doing so in fact

 

[jefemeister]

I came on in this kind of late so I'm not sure if this helpful but...

It seems the 10K2 DSP switches its internal clock on a sample rate change. I would not have guessed that. Usually DSPs have a DMA where the peripherals can constantly run in the background of the core. All the data is managed "automatically" after a ton of BIOS setup. You can change the rates on the peripherals and keep the same core clock, the interrupts will just hit at different times. Glassman touched on this, but modern DSP systems are multi-tasking which means you have a bunch of applications running simultaneously and use a complex buffer management system to share data and cycles amongst each other.

The fact that it changes the core clock along with the sample rate probably means that there is no resampling but there is definitely some clock management.

It appears the 0404 only has a 24.576MHz crystal which would preclude the use of 44.1 rates directly. 48kHz based rates can not be converted to 44.1 based rates using standard clock division. A PLL must be used to do this and jitter will definitely be increased. You can vastly improve this with a good power supply and a sweet loop filter. But the PLL is also required to latch onto the externally generated clock to limit asynchronous behavior so you might as well use it. I've often seen the various bit rates generated by two seperate oscillators. One to control 32/48 rates and another for the odd-ball 44.1 rates. Sounds like the 1212 does this.

Someone mentionedd FPGAs are taking over DSPs. In my experience that is not the case. I know, for example, Altera provides both DSP and microprocessor cores that run straight off the FPGA resources. This is cool if you need to do a lot of data transformations, FIFOs, clock stuff, etc and the DSP part is simple. There is no substitute for a true DSP when doing more complicated things though. But I agree the market is definitely starting to merge a bit.

 

[Lilac_Wine]

FPGAs can beat dedicated DSPs at very wide functions. While it is true that FPGAs will never completely replace DSPs, for some tasks FPGAs are more efficent. In addition, if you are already putting an FPGA on the board, it may make sense to have it do a bunch of things, including DSP.

But point taken - DSP processors are not going away.

By the way, this is a great thread. Having just bought a 0404, it is great to have a better idea of what it is doing.

 

[pbirkett]

So have we reached any conclusion about this yet? Does it, or does it not, in a nutshell, resample to 48 KHz?

 

[Glassman]

of course not, we were talking about how exactly it works..

 

[gaboo]

Here is rev. engineered (based mainly on the patents) pinout, of the 10K1 chip. It uses a 24MHz (not KHz) external clock for the core on pin 4. Even this old bummer supports 12Mhz external I2S bit clock for converters on pin 10. This and the IEEE Micro article make me think that resampling was more a matter of mentality (saving money on external components) than a hardware limitation even for the old Live/APS.

 

[Glassman]

those MHz values are rounded of course, it should be 512*48=24.576MHz (core clock), 256*48=12.288MHz (AC'97 bitclock/ I2S master clock(?)) and 64*48=3.072MHz (I2S bitclock)..

 

[gaboo]

I thought I was the pedantic guy.

 

[gaboo]

Here's the original article from DAFX98 conference on the DSP core (called FX8010) included in the 10K1 chip. I suspect that most of the kx documentation was based on this paper.