forums.ps2dev.org

gawd · Joined: 09 Feb 2005 Posts: 28 Location: Israel

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]

emoon · Joined: 18 Jan 2004 Posts: 91 Location: Stockholm, Sweden

Great stuff.

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

.emoon

gawd · Joined: 09 Feb 2005 Posts: 28 Location: Israel

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)

emoon · Joined: 18 Jan 2004 Posts: 91 Location: Stockholm, Sweden

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. · Joined: 22 Feb 2004 Posts: 2906

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

gawd · Joined: 09 Feb 2005 Posts: 28 Location: Israel

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

pixel · Joined: 30 Jan 2004 Posts: 791

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.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

gawd · Joined: 09 Feb 2005 Posts: 28 Location: Israel

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.

pixel · Joined: 30 Jan 2004 Posts: 791

RPC will use DMA, but will block until the reply is sent.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

blackdroid · Joined: 17 Jan 2004 Posts: 564 Location: Sweden

nice stuff, thumbs up!
_________________
Kung VU

Saotome · Joined: 03 Apr 2004 Posts: 182

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);
_________________
infj

BraveDog · Joined: 30 Dec 2004 Posts: 29 Location: Cleveland

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

gawd · Joined: 09 Feb 2005 Posts: 28 Location: Israel

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 · Posted: Tue Apr 26, 2005 7:09 pm Post subject:

Great stuff!

I look forward to the callback functionality.

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

evilo · Joined: 22 Apr 2004 Posts: 230

great work gawd !

one little request :

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

thanks !

Shazz · Posted: Thu May 05, 2005 7:43 pm Post subject:

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...
_________________
- TiTAN Art Division -
http://www.titandemo.org