Release Some Dsp Codecs Out

[Butterman]

I'd rather downscale 720p stuff than upscale SD stuff.

 

[EdCa22]

Is this dsp designed to be able to accelerate encoding as well? it would be pretty handy if it could do at least near RT encoding or better

cause chances are you don't have a video DSP in your computer and graphics card accelerated encoding isn't up to snuff yet

Several people have already pointed out that a DSP is a general purpose chip (normally just means its good at (real-time) math)... I also wanted to point out that everyone talks about codecs running on the DSP and that codec means code-decode - thus from this you can infer anyway that it can of course it can encode!

 

[borgqueenx]

so if i understand correctly, Dsp is a codec that allows you to watch high quality video's on the pandora, with only using 15% of the cpu?
so you can watch about 60 hours of video or something like that?

 

[lulzfish]

so if i understand correctly, Dsp is a codec that allows you to watch high quality video's on the pandora, with only using 15% of the cpu?
so you can watch about 60 hours of video or something like that?

Well, if you're being serious, then .. almost.
The DSP is the circuit / chip [idfk] that acts as a sort of secondary math processor to the main CPU.
There will be software codecs available for it for video, and they will move most of the math involved to the DSP, greatly reducing the CPU load.

However, a 15% loaded CPU and a 60% loaded DSP and a screen and SD card controller do not use 15% of the power of a 90% loaded CPU and screen and SD card controller with no DSP.

I would say the DSP codecs might double battery life while playing video, but the DSP itself will consume some power, and the CPU will still do a bit of work. [Setting up DMA from the SD card into the DSP, probably]

Let us say that you could at least watch 2 or 3 full-length movies without worrying about your battery.

 

[bzar]

To clarify for everyone, DSP means Digital Signal Processor, which basically is a specialized processor built to receive a digital signal, do stuff to it output the results. The "stuff" can be anything from voice manipulation/enhancing to audio/video decoding to pattern recognition. DSPs are usually used for real-time applications, when you need a fixed, minimal delay between the data input and output, for example in echo filtering.

I minor in digital signal processing, which for some reason utilizes these things quite a lot. I have a feeling I'm going to have fun with this little piece of silicon inside the pandora when it arrives

 

[lulzfish]

To clarify for everyone, DSP means Digital Signal Processor, which basically is a specialized processor built to receive a digital signal, do stuff to it output the results. The "stuff" can be anything from voice manipulation/enhancing to audio/video decoding to pattern recognition. DSPs are usually used for real-time applications, when you need a fixed, minimal delay between the data input and output, for example in echo filtering.

I minor in digital signal processing, which for some reason utilizes these things quite a lot. I have a feeling I'm going to have fun with this little piece of silicon inside the pandora when it arrives



For some reason I suspect the DSP will make audio manipulation in real-time possible, or fun things like procedural sound generation.

Do you think it can do things like that?

 

[bzar]

To clarify for everyone, DSP means Digital Signal Processor, which basically is a specialized processor built to receive a digital signal, do stuff to it output the results. The "stuff" can be anything from voice manipulation/enhancing to audio/video decoding to pattern recognition. DSPs are usually used for real-time applications, when you need a fixed, minimal delay between the data input and output, for example in echo filtering.

I minor in digital signal processing, which for some reason utilizes these things quite a lot. I have a feeling I'm going to have fun with this little piece of silicon inside the pandora when it arrives



For some reason I suspect the DSP will make audio manipulation in real-time possible, or fun things like procedural sound generation.

Do you think it can do things like that?

DSPs in general are used for those things and I don't think the one in pandora will be any different. I'll have to do some digging though to be certain. But if it can be used to decode MP3s, I don't see why it wouldn't be able to do the things you mentioned.

 

[ldesnogu]

For some reason I suspect the DSP will make audio manipulation in real-time possible, or fun things like procedural sound generation.

Do you think it can do things like that?

Certainly. The only issue is that typically procedural sound generation uses floating-point and the C64 is fixed-point only. Search on the web for csound + DSP.

 

[Username]

This is still good news then?

 

[Phawx]

I had hopes that the DSP could have handled some of the FPU limitations within NEON. I didn't know the DSP was fixed-point only

This also means if anything was to make heavy use of NEON, OCing capabilities go way down, right?

 

[lulzfish]

For some reason I suspect the DSP will make audio manipulation in real-time possible, or fun things like procedural sound generation.

Do you think it can do things like that?

Certainly. The only issue is that typically procedural sound generation uses floating-point and the C64 is fixed-point only. Search on the web for csound + DSP.

Yeah, the DSP is fixed-point, and it's really meant to process streams of audio/video data, not arbitrary floating-point numbers, so it wouldn't work well anyway.

I'm not very concerned about this, because I don't think floating point is really necessary to the whole 'sound' thing, and I would appreciate any amount of procedurally generated / modified sound I can get.

 

[EdCa22]

To clarify for everyone, DSP means Digital Signal Processor, which basically is a specialized processor built to receive a digital signal, do stuff to it output the results. The "stuff" can be anything from voice manipulation/enhancing to audio/video decoding to pattern recognition. DSPs are usually used for real-time applications, when you need a fixed, minimal delay between the data input and output, for example in echo filtering.

I minor in digital signal processing, which for some reason utilizes these things quite a lot. I have a feeling I'm going to have fun with this little piece of silicon inside the pandora when it arrives



For some reason I suspect the DSP will make audio manipulation in real-time possible, or fun things like procedural sound generation.

Do you think it can do things like that?


Heh! The DSP in the pandora is a BEAST compared to the majority of DPS chips... I used a dsPIC (a commonly used DSP microprocessor) to make a completely programmable guitar pedal (it has real-time audio processing with fourier transforms...fairly intensive), and that was a 40MHz chip... the DSP is certainly a very powerful extra in the pandora. It is a pity that most applications wont use it because they will compile to the arm core only. I have been thinking about writing an extension to octave (which is open source matlab) to allow it to be used to implement parts of octave programs, particularly control system analysis stuff to be done in real time. Coupled with some kind of simple external IO sampling this would be a very nice piece of testing and experimenting equipment...it is just a shame that there is no fast IO accessible on the pandora. Perhaps I will go down the USB route for this and use a fast-ish external micro with enough memory to buffer data before picking it up on USB (due to the very un-deterministic behaviour of USB) (thinking 'out loud' here).

 

[ldesnogu]

Yeah, the DSP is fixed-point, and it's really meant to process streams of audio/video data, not arbitrary floating-point numbers, so it wouldn't work well anyway.

I'm not very concerned about this, because I don't think floating point is really necessary to the whole 'sound' thing, and I would appreciate any amount of procedurally generated / modified sound I can get.

Again do some research, and you'll see that most Audio DSP stuff is floating-point, at least everything that's supposed to provide good quality.
That doesn't mean you can't get good quality out of c64x, just that it might be more painful

 

[Exophase]

I too can vouch for how powerful the C6x DSPs are, have been using a C67x for a while (and save for the lack of floating point, the C64x+ ones are better). Can perform 8 instructions per cycle with a good amount of functional redundancy in the execution units, with a large number of registers (and a "register multiplexing" quirk that works out of the delay slots which reduces the need for register renaming). Cache latencies are very good as well, and if the OMAP3530 has the kind of EDMA available on SoC I've been using then it's quite powerful as well.

Funny thing is that this 8-way VLIW architecture is hardly anything new, as the family of DSPs has been around for over a decade.

EdCa22; Do you want analog data? If so, the microphone port might suffice, although I don't know exactly what the sampling threshold is for the A2D it's hooked up to. If you were planning on supplying your own high frequency A2D to a digital input (or want pure digital) then that's another story.

 

[EdCa22]

Yeah, the DSP is fixed-point, and it''s really meant to process streams of audio/video data, not arbitrary floating-point numbers, so it wouldn''t work well anyway.

I''m not very concerned about this, because I don''t think floating point is really necessary to the whole ''sound'' thing, and I would appreciate any amount of procedurally generated / modified sound I can get.

Again do some research, and you'll see that most Audio DSP stuff is floating-point, at least everything that's supposed to provide good quality.
That doesn't mean you can't get good quality out of c64x, just that it might be more painful

I'd have to disagree here... high quality audio processing certainly can be handled well and in real time on fixed point DSPs, you just have to be a bit careful about what you're doing...I'd also argue that most devices that are doing real time audio processing (independently of a desktop PC) are implemented on non-floating point DSP chips or even just low power general purpose microprocessors. Note that here there is a distinct difference between general audio processing and compression/decompression (codecs) because there is a lot more number crunching required to implement a codec comapred to the majority of audio processing applications which are generally just fairly simple simple digital filters. So it really depends on the application. Floating point is certainly always an advantage.

I too can vouch for how powerful the C6x DSPs are, have been using a C67x for a while (and save for the lack of floating point, the C64x+ ones are better). Can perform 8 instructions per cycle with a good amount of functional redundancy in the execution units, with a large number of registers (and a "register multiplexing" quirk that works out of the delay slots which reduces the need for register renaming). Cache latencies are very good as well, and if the OMAP3530 has the kind of EDMA available on SoC I've been using then it's quite powerful as well.

Funny thing is that this 8-way VLIW architecture is hardly anything new, as the family of DSPs has been around for over a decade.

EdCa22; Do you want analog data? If so, the microphone port might suffice, although I don't know exactly what the sampling threshold is for the A2D it's hooked up to. If you were planning on supplying your own high frequency A2D to a digital input (or want pure digital) then that's another story.

I havent checked, but I assumed the microphone port could only run at 44KHz or so (or perhaps 88KHz if you can use both channels and have a precise phase shift between them)... perhaps it can do more if its using a general purpose A2D..and this is fine for audio and might be useful for other things too (especially testing)...however, apart from wanting to do both analogue and digital input and output, I was thinking of something that can run at MHz rather than KHz. So unfortunately this wont help in the long term....I think USB is the only option.

 

[lulzfish]

Yeah, the DSP is fixed-point, and it''s really meant to process streams of audio/video data, not arbitrary floating-point numbers, so it wouldn''t work well anyway.

I''m not very concerned about this, because I don''t think floating point is really necessary to the whole ''sound'' thing, and I would appreciate any amount of procedurally generated / modified sound I can get.

Again do some research, and you'll see that most Audio DSP stuff is floating-point, at least everything that's supposed to provide good quality.
That doesn't mean you can't get good quality out of c64x, just that it might be more painful

I'd have to disagree here... high quality audio processing certainly can be handled well and in real time on fixed point DSPs, you just have to be a bit careful about what you're doing...I'd also argue that most devices that are doing real time audio processing (independently of a desktop PC) are implemented on non-floating point DSP chips or even just low power general purpose microprocessors. Note that here there is a distinct difference between general audio processing and compression/decompression (codecs) because there is a lot more number crunching required to implement a codec than for the majority of audio processing applications.


I had a bunch of questions written here, but it mostly comes down to this:

How am I going to run code on the DSP and synchronize it with my CPU code?

 

[EdCa22]

I had a bunch of questions written here, but it mostly comes down to this:

How am I going to run code on the DSP and synchronize it with my CPU code?

I haven't looked at the specifics, however I'd imagine that you'd buffer the data in the DSPs memory and then request it asynchronously in your main program running on the CPU whenever you need some results. Or the inverse when inputting data - you provide data to the DSP when you have some and then the DSP works on it and buffers the results.

Of course, this is asynchronous data exchange. To do it synchronously you would probably do the same but make your main program access and provide data at regular intervals. Generally it is quite hard to guarantee a deterministic response in linux so precise synchronisation would be difficult, but the point is that the actual processing would happen more-or-less deterministically and in real time on the DSP, concurrently to whatever else you're doing on the main processor, and its unlikely you need it to be _that_ regular anyway. If you are relying on a result from the DSP then you will have to block your program execution until it has finished, however this isnt really what the DSP is there for. Someone else probably knows more about this, certainly about the precise mechanisms. (Exophase? Laurent?)

This is essentially how a lot of networking is done (and indeed operating system IO in general), so you can use most network coding principles as an analogy.

 

[Exophase]

I had a bunch of questions written here, but it mostly comes down to this:

How am I going to run code on the DSP and synchronize it with my CPU code?

You'd upload it using some kind of gateway (maybe a Linux device..) that TI is supposed to be providing.

You synchronize it the same way you synchronize any other multithreading code that's safe for running on multiple processors concurrently. If you don't know about this kind of synchronization then you'll want to read up.

 

[lulzfish]

Well, yes, I suppose I'd pass the DSP a memory pointer for DMA or something, but I was actually asking about the program code running on the DSP. Is there going to be a compiler setting on a regular C++ compiler or would I use something like an assembler? Is it even part of the regular machine code? I know for GLSL you pass the program as a string to a compiler found [I think] in the driver program.

I had a bunch of questions written here, but it mostly comes down to this:

How am I going to run code on the DSP and synchronize it with my CPU code?

You'd upload it using some kind of gateway (maybe a Linux device..) that TI is supposed to be providing.

You synchronize it the same way you synchronize any other multithreading code that's safe for running on multiple processors concurrently. If you don't know about this kind of synchronization then you'll want to read up.


? It's not part of the compiled machine code?

As for synchronizing, I have a vague idea of how that works, as I've done introductory networking and threading stuff in Java.

Here's a more formal list of questions:
1. What program code will be running on the DSP?
2. How do I compile that code and call it from my CPU program?
3. How do I get data from the DSP into the sound output? Just use something like ALSA?

 

[Exophase]

? It's not part of the compiled machine code?

Probably not. Will probably be an object file or binary that the interface takes.

As for synchronizing, I have a vague idea of how that works, as I've done introductory networking and threading stuff in Java.

Here's a more formal list of questions:
1. What program code will be running on the DSP?

A C64x+ program.

2. How do I compile that code and call it from my CPU program?

You compile it using TI's freely avaible C6x C compiler. Or assembler, if you're good at that sort of thing.

You wouldn't "call" it from your program, you'd upload it using their tools, which probably consists of something available at runtime (not something you compile in), but I don't really know.

3. How do I get data from the DSP into the sound output? Just use something like ALSA?

Linux isn't running on the DSP and you wouldn't want to try interfacing with it directly. You'd probably want to write audio to somewhere the host program running on the Cortex-A8 can see it and have it stream it to the audio device.