iOS Audio

I just updated to the newest SDL build to see how things are shaping up for iOS, and this one is a slight step forward. It still fails to initialize audio, but this one fails right away in the init function with:

SDL: Could not init (Error: No available audio device)

This is better then before, when it would init but then would freeze on initializing audio and never play a sound.

That’s my progress report :slight_smile: If there’s any further builds you guys would like me to test, feel free to post to this list (or email me) and I’ll test them out.

[>] Brian

Hey i am too getting some audio initialisation problem with latest
version of sdl on ios! In my application it just gives “Init audio…
failed”, and it happens on a clean compile of both latest and
pre-merge of ios and mac coreaudio.

Do you remember which revision was working (eg. gave another error
message) for you?
Best
VittorioOn Thu, Aug 18, 2011 at 3:51 AM, Brian Barnes wrote:

I just updated to the newest SDL build to see how things are shaping up for
iOS, and this one is a slight step forward. ?It still fails to initialize
audio, but this one fails right away in the init function with:
SDL: Could not init (Error: No available audio device)
This is better then before, when it would init but then would freeze on
initializing audio and never play a sound.
That’s my progress report :slight_smile: ?If there’s any further builds you guys would
like me to test, feel free to post to this list (or email me) and I’ll test
them out.
[>] Brian


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SO, i did took advantage of the situation, and learned how to properly
run hg bisect! neat stuff
The last working changeset for me is 2cf94ca4ad24 which is just the
revision before the two coreaudio targets got merged

Here’s the output of bisect run from 70b6f92e4539 to 640c67302f8e and
the revision found is unfortunately relevant to the audio section
changeset: 5596:d4b2f6543074
user: Ryan C. Gordon
date: Thu Aug 04 00:45:09 2011 -0400
summary: Merged Mac OS X and iOS audio targets.

Ryan could you help us out about this issue?
Thanks
VittorioOn Wed, Aug 24, 2011 at 9:18 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:

Hey i am too getting some audio initialisation problem with latest
version of sdl on ios! In my application it just gives “Init audio…
failed”, and it happens on a clean compile of both latest and
pre-merge of ios and mac coreaudio.

Do you remember which revision was working (eg. gave another error
message) for you?
Best
Vittorio

On Thu, Aug 18, 2011 at 3:51 AM, Brian Barnes wrote:

I just updated to the newest SDL build to see how things are shaping up for
iOS, and this one is a slight step forward. ?It still fails to initialize
audio, but this one fails right away in the init function with:
SDL: Could not init (Error: No available audio device)
This is better then before, when it would init but then would freeze on
initializing audio and never play a sound.
That’s my progress report :slight_smile: ?If there’s any further builds you guys would
like me to test, feel free to post to this list (or email me) and I’ll test
them out.
[>] Brian


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Here’s the output of bisect run from 70b6f92e4539 to 640c67302f8e and
the revision found is unfortunately relevant to the audio section
changeset: 5596:d4b2f6543074
user: Ryan C. Gordon<@icculus>
date: Thu Aug 04 00:45:09 2011 -0400
summary: Merged Mac OS X and iOS audio targets.

Man, I’m breaking things left and right…ok, I’ll look into this.

–ryan.

The last working changeset for me is 2cf94ca4ad24 which is just the
revision before the two coreaudio targets got merged

I forgot to update the iOS config header, so it didn’t compile in the
CoreAudio support at all. This is fixed now in Mercurial. Can you
confirm this solves the problem for you?

Thanks,
–ryan.

Hey Ryan, 91c9a69dd2ad works great for me, glad it was an easy fix!
However the recent merge of one of the gsoc project is causing quite a
number of compilation error, at least for the ios version, but i
believe it’s just a matter of headers again?
Thanks a lot for your support!
VittorioOn Mon, Aug 29, 2011 at 6:30 AM, Ryan C. Gordon wrote:

The last working changeset for me is 2cf94ca4ad24 which is just the
revision before the two coreaudio targets got merged

I forgot to update the iOS config header, so it didn’t compile in the
CoreAudio support at all. This is fixed now in Mercurial. Can you confirm
this solves the problem for you?

Thanks,
–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ryan wrote:

I forgot to update the iOS config header, so it didn’t compile in the
CoreAudio support at all. This is fixed now in Mercurial. Can you
confirm this solves the problem for you?

I’m not the original poster but audio on iOS has never worked for me, so I grabbed the new copy and tried it. The new error is gone, but it’s back to the old error:

Error ‘!dat’ trying to set the (null) audio devices’ sample rate

And no sound.

Also, the project contains both the default config and the iOS config file; I would suggest that you put a copy of the iOS config file (as SDL_config.h) into the iPhone XCode directory, and point directly at that one. Then nobody will have to switch around files to build it. You could do this same thing for the regular XCode build, the MSVC build, etc. Anybody building it with the tools wouldn’t need the extra step (which I always forget and wonder for a minute why it’s trying to pull in X11 stuff :slight_smile: ). It’s a bit more user friendly and makes getting SDL for the people building with tools (which I suspect is a lot of them) a two step process – get and compile.

[>] Brian

I’m trying to make a patch to get multi touch in Android working. I’ve posted
what I have so far in http://bugzilla.libsdl.org/show_bug.cgi?id=1294, but as
I’ve mentioned in the bug report I’m having a big problem with the float
coordinates where the touch occurs. In a nutshell, they arrive safely at
Android_OnTouch, but when I pass them to SDL_SendTouchMotion or
SDL_SendFingerDown they get corrupted, and I’ve been hitting my head against
the wall for the good part of the day so I thought I’d throw it out there in
case anyone has an idea of what the problem might be.

Thanks for any help!

Gabriel.

Also, the project contains both the default config and the iOS config
file; I would suggest that you put a copy of the iOS config file (as
SDL_config.h) into the iPhone XCode directory, and point directly at
that one.

This tends to cause problems if you run the configure script, and THEN
try to use a project file. Is this where you’re seeing issues?

–ryan.

To answer my own message, I forgot the SDL_touch_c.h header in SDL_androidtouch.c, and while it compiles without warnings, there’s probably some calling convention or float precision issue that comes up because of this. Anyway, it’s fixed. I’ll upload a corrected patch soon.------------------------
Gabriel Jacobo
mdqinc.com

Nice work!

Yes, float parameters are very sensitive to calling convention on ARM, I’ve been bitten by this when I attempted to wrap GLES functions and my function pointers had a different calling convention than
the functions they were being pointed at.

I don’t know specifically what calling convention is involved here, but make sure it matches :)On 08/29/2011 06:24 PM, gabomdq wrote:

To answer my own message, I forgot the SDL_touch_c.h header in SDL_androidtouch.c, and while it compiles without warnings, there’s probably some calling convention or float precision issue that comes
up because of this. Anyway, it’s fixed. I’ll upload a corrected patch soon.


Gabriel Jacobo
mdqinc.com


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Good work: I’d be very interested to see working multitouch at some point :)On 30 August 2011 14:24, Forest Hale wrote:

Yes, float parameters are very sensitive to calling convention on ARM, I’ve
been bitten by this when I attempted to wrap GLES functions and my function
pointers had a different calling convention than the functions they were
being pointed at.

I don’t know specifically what calling convention is involved here, but
make sure it matches :slight_smile:

On 08/29/2011 06:24 PM, gabomdq wrote:

To answer my own message, I forgot the SDL_touch_c.h header in
SDL_androidtouch.c, and while it compiles without warnings, there’s probably
some calling convention or float precision issue that comes
up because of this. Anyway, it’s fixed. I’ll upload a corrected patch
soon.

------------------------------------------------------------
------------------------------------------------------------
------------------------------------------------------------

Gabriel Jacobo
mdqinc.com

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org