Sound fixes

[GoogleCodeExporter]

Seleuco, some good news, I've fixed the sound driver!!! No need for the low 
latency option as I've fixed the AudioQueue which gives zero latency and works 
with all frequencies, stereo etc. The main fix is also that it no longer loses 
sync. You were almost there with the code, it just need a bit more tweaking.

Using the AudioQueue also seems to get rid of some of the juddering (compared 
to AudioUnits). It's working real nice, I've attached the mame executable 
(compiled at armv7, ipad/3gs for now). I'll upload the source changes once I've 
done some more fixes/testing.

Thanks Seleuco, this has finally got me into programming iOS - it's been quite 
a few years since I've worked on MAME too.

Original issue reported on code.google.com by squid123...@gmail.com on 24 Jul 2011 at 9:56

Attachments:

• mame_test.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Amazing work... Please attach me the source patches... I really Curious about 
your changes... I have nearly finished a new analog touch control system... 
Finally is playable starwors without a wii classic controller :)I think is a 
big improvement on playability... So I would like to publish a new version in a 
few days, it would be nice to include your patches also...

Original comment by seleuco....@gmail.com on 25 Jul 2011 at 12:21

[GoogleCodeExporter]

Here they are. "minimal.cpp" has most of the changes, there's only a one line 
change in "sound.cpp". I've removed the AudioUnit (low latency) code as it is 
not needed anymore. 

Changes are: 
* correct rate, stereo, fps from MAME engine are processes correctly by the 
AudioQueue sound functions and buffers.
* sound going out of sync fixed
* stereo support.
* multiple sound rates supported
* 44khz stereo seems to work well with most games on iPad 1.
* it seems to have fixed jerky gameplay, possibly it was the AudioUnit code 
causing that. Much smoother.

I have also been working on the Cyclone code but have hit a stopper with the 
ancient Assembler in XCode (and toolchain). It won't fully compile with those. 
I've tried contacting the Cyclone authors to see if they can help - I don't 
think much work is involved but I don't know ARM assembler. They recently 
removed the R9 register usage in the Cyclone code. I've finally got the 
toolchain 3.1.2 working on Ubuntu 9.10 also, but I've realised it probably 
isn't required as XCode seems to do everything I need. I was hoping the 
toolchain supported ELF objects, which would have helped compiling the Cyclone 
code, but it also generates Mach-o objects.

Regards
Simon Quinn

Original comment by squid123...@gmail.com on 25 Jul 2011 at 9:47

Attachments:

• soundfixes_SQ.zip

[GoogleCodeExporter]

Great news on the analog touch control, I love starwars etc.

Original comment by squid123...@gmail.com on 25 Jul 2011 at 9:49

[GoogleCodeExporter]

I wiil be out of home two days... So I cant add your changes till then. I ask 
me one thing... I supposed that audiounit is the low level sound API used for 
apple to do real time audio.  So I suppose that the overhead is less, since it 
not pass througth mixer and the latency is far  better... The drawback is that 
you must queue the sound buffers and that is not a well know iOS API... Limited 
sound rates ...since it is not preprocess by mixer... I hope it is a little 
faster than it's counterpart audioqueue...  what do you think?

Original comment by seleuco....@gmail.com on 25 Jul 2011 at 11:13

[GoogleCodeExporter]

Yes, the AudioUnit is very low level. As the Apple Docs say it would normally 
only be used for critical timing stuff like music sequencers and VOIP that must 
have very low latency for simultaneous I/O. The latency we are talking about 
with game sound and the audioqueue is not noticeable, it's still pretty low 
latency with the audioqueue, i.e. accurate to a frame or two. I haven't noticed 
any latency issues with the new code. Using such low level calls seems to cause 
delay issues (stuttering), these don't seem to appear with the queue as it is 
threading the load into the actual sound hardware through the O/S.

I had the same issue with ZodMAME on the Tapwave, first used the low level API 
but had stuttering issues, then went to the equivalent of the queue and it 
solved those with no performance hit. 

Original comment by squid123...@gmail.com on 25 Jul 2011 at 1:46

[GoogleCodeExporter]

You right, there had stuttering with audiounit with very demanding games, 2 
frames are 40 ms more or less delay it is good enough with your audioqueue 
fixes... :)

Original comment by seleuco....@gmail.com on 25 Jul 2011 at 2:27

[GoogleCodeExporter]

I have been able to analyze your fixes with mi little iPhone... It seems that 
the problem was relates do a fixed frame count and not setting the frames  
according to the games fps... :) anyway I need my desktop computer ... To get 
on the deeper ;)

Original comment by seleuco....@gmail.com on 25 Jul 2011 at 2:55

[GoogleCodeExporter]

Closed

Original comment by squid123...@gmail.com on 22 Sep 2011 at 12:13

• Changed state: Done

[GoogleCodeExporter]

Original comment by squid123...@gmail.com on 22 Sep 2011 at 1:05

• Changed state: Fixed