Announcing audsrv 0.75

gawd · Post by **gawd** » Mon Apr 25, 2005 12:20 am

Greetings!

I am very pleased to announce the CVS import of audsrv 0.75. Audsrv comes to replace sjpcm, and provide an easy and stable way to utilize the SPU2. The EE side code is available under /ee/rpc/audsrv, and the IOP side is under /iop/sound/audsrv. A sample is available under /ee/rpc/audsrv/sample.

Features:
* demux on IOP side
* upsampling on IOP side (currently supports 11025, 12000, 22050 and 24000)
* stream based, not related to vsyncs (at all!)
* loaded with documentation :)

In the making:
* 8 bit support
* Mono support
* cdda support
* fill audio callback

Please send feature requests, and bug reports as private messages. SDL integration will be done soon.

Cheers!
-- gawd.
[/u]

Post by **emoon** » Mon Apr 25, 2005 12:24 am

Great stuff.

One feature i would like to see is to be able to stream adpcm stream(s) from EE

.emoon

gawd · Post by **gawd** » Mon Apr 25, 2005 12:28 am

I thought about it. Would you use adpcm for music as well? I thought of adding some primitive mixer, to allow playing voices (adpcm), sound effects (samples) and background music (either another sample, or cdda)

Post by **emoon** » Mon Apr 25, 2005 12:34 am

Yes, i was thinking about using adpcm for music for the demo.

Right now i use madplay, but with all this GPL shit going on i rather
switch to something free and that also eats less CPU.. even if i dont
use the EE that much :)

.emoon

J.F. · Post by **J.F.** » Mon Apr 25, 2005 4:11 am

Other common sample rates you should support in resampling to 48K are 32000 and 44100. Those are particulary common when decoding mp3 streams.

gawd · Post by **gawd** » Mon Apr 25, 2005 8:39 am

32000 and 44100 already added. will submit all changes soon. any feature requests?

Post by **pixel** » Mon Apr 25, 2005 11:42 am

Errr

Is it just me, or is it blocking all the way around ?

So, for me, the actual requests are:

-) Using DMA transferts to move data from EE to IOP instead of using RPC (that is, the RPC should try to see where and how much data it can send, and then, set up a background DMA for it to fill in the buffers in the IOP)

-) Having a callback with a threshold so that the EE can have a playing thread which is blocked most of the time, and woken up by the callback from IOP when the IOP is okay to recieve more data (instead of just blocking when trying to send new data)

For example, in the Beats of Rage PS2 port, the sound data works by using double buffering. EE asks the player IRX to allocate two sound buffers of 2048 bytes, and sets a callback so that the IOP warns the EE when the buffer is ready to get refilled. Which the EE does by dma'ing data into the buffer.

gawd · Post by **gawd** » Mon Apr 25, 2005 3:41 pm

I thought RPC uses DMA. If not, I will implement that, no biggie. How faster will that be?

As for the blocking issue. Check out the example, you are supposed to use audsrv_wait_audio(2048), which will block your EE thread, until there's enough space on the ringbuffer. I can implement a threshold callback, I already have something for IOP itself, it should be easy to add a Cmd Handler.

Post by **pixel** » Mon Apr 25, 2005 5:24 pm

RPC will use DMA, but will block until the reply is sent.

Post by **blackdroid** » Mon Apr 25, 2005 7:04 pm

nice stuff, thumbs up!

Saotome · Post by **Saotome** » Mon Apr 25, 2005 7:13 pm

you could also use a "non-blocking" RPC. but i believe you dont get a reply then. so if you dont need the reply from IOP...

SifCallRpc(&cdata, DUMMY_FUNC01, SIF_RPC_M_NOWAIT, data, 16, data, 0,0,0);

BraveDog · Post by **BraveDog** » Tue Apr 26, 2005 1:27 am

Works great in the emu I am working on.
Thank you gawd!

gawd · Post by **gawd** » Tue Apr 26, 2005 5:43 pm

Well.

All of the functions are synchronous anyway. Even send_audio, which returns the number of bytes queued (just in case you didn't call wait_audio before hand and never know what hit you.) I don't think the speed pentaly for RPC instead of DMA is that big. I mean, for 48k you send between 50-100 packets a second. Is that much? I have no problem moving to DMA, but I still don't understand what the fuss it all about.

Thanks for the positive remarks, BraveDog.

Many people started using audsrv, I would just like to know how easy/hard the integration was. For future reference.

Thanks.
--gawd.

rinco · Post by **rinco** » Tue Apr 26, 2005 7:09 pm

Great stuff!

I look forward to the callback functionality.

Also, would have been nice to know freesd needs to be loaded.

evilo · Post by **evilo** » Wed Apr 27, 2005 9:21 am

great work gawd !

one little request :

possiblity to queue left & right buffers separately (as it was the case with isjpcm).

thanks !

Shazz · Post by **Shazz** » Thu May 05, 2005 7:43 pm

Just to let people know :

- Gawd added mono, stereo and upsampling support for :
22050, 16, 1, up_22050_16_mono
22050, 16, 2, up_22050_16_stereo
24000, 16, 2, up_24000_16_stereo
44110, 16, 2, up_44100_16_stereo
44100, 16, 1, up_44100_16_mono
44100, 16, 2, up_44100_16_stereo
48000, 16, 2, up_48000_16_stereo

- Pixel has exported audsrv functions to use it from IOP modules

More to come...