RE: Race condition in some iOS devices.
Daniel Varela <[email protected]> Mon, 4 Mar 2013 11:08:39 +0000
| Newsgroups | gmane.comp.lib.openal |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1841785219== Content-Type: multipart/alternative; boundary="----------MIME-890688297-1063364609-delim" This is a multi-part message in MIME format. ------------MIME-890688297-1063364609-delim Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Eric=2C I=27ll do that since this bug is quite annoying=2E I have found a workaround to make pause and resume work as intended in this= situation=3A 1=29 Store AL=5FSAMPLE=5FOFFSET value of the source at the moment of pausin= g it=2E 2=29 Calling alSourcePlay twice on resuming=2E This will cause the buffer t= o replay=2E 3=29 Set the AL=5FSAMPLE=5FOFFSET on the voice=2C using the same offset sto= red at the moment of pausing it=2E This steps worked for me=2E=20 Hope this helps to other people that find the same issue=2E=5B Daniel Varela =7C Audio Programmer Tech Team =7C Blitz Games Studios Ltd=2E -----Original Message----- From=3A Eric Wing =5Bmailto=3Aewmailing=40gmail=2Ecom=5D=20 Sent=3A 03 March 2013 00=3A21 To=3A Daniel Varela Cc=3A openal=40opensource=2Ecreative=2Ecom Subject=3A Re=3A =5BOpenal=5D Race condition in some iOS devices=2E On 3/1/13=2C Daniel Varela =3Cdvarela=40blitzgamesstudios=2Ecom=3E wrote=3A= =3E Hello=2E =3E =3E As described in this link=2C there is a race condition in some iOS=20= =3E devices in which subsequent callings to pause resume over an OpenAL=20= =3E source voice does not works=2E =3E Before we just fixed it by calling alSourcePlay twice when resuming=20= =3E the sound=2C but it causes the buffer to restart and we need to have=20= =3E several tracks synchronized for interactive music purposes and this=20= =3E solution is no longer valid=2E =3E =3E I was wondering if someone has experienced the same issue=2E =3E =3E Thanks=2E =3E =3E Daniel Varela =7C Audio Programmer =3E Tech Team =7C Blitz Games Studios Ltd=2E =3E =3E I filed that bug=2E I don=27t think it has been fixed=2E Please file a dupl= icate bug with Apple to raise the priority=2E Thanks=2C Eric -- Beginning iPhone Games Development http=3A//playcontrol=2Enet/iphonegamebook/ *********** Blitz Games Studios Limited is registered in England =28company no=3A 24829= 13=29 with registered office at Regent Square House=2C The Parade=2C Leamin= gton Spa=2C Warwickshire=2C CV32 4NL=2C UK=2E This message is intended sole= ly for the addressee and may contain confidential information=2E If you hav= e received this message in error please send it back to us and immediately= and permanently delete it from your system=2E Do not use=2C copy or disclo= se the information contained in this message or in any attachment=2E Please= also note that transmission cannot be guaranteed to be secure or error-fre= e=2E *********** ------------MIME-890688297-1063364609-delim Content-Type: text/html; charset="us-ascii" <html> <body> Thanks Eric, I'll do that since this bug is quite annoying.<br><br>I have found a workaround to make pause and resume work as intended in this situation:<br> <br>1) Store AL_SAMPLE_OFFSET value of the source at the moment of pausing it.<br>2) Calling alSourcePlay twice on resuming. This will cause the buffer to replay.<br> 3) Set the AL_SAMPLE_OFFSET on the voice, using the same offset stored at the moment of pausing it.<br><br>This steps worked for me. <br> Hope this helps to other people that find the same issue.[<br><br>Daniel Varela | Audio Programmer<br>Tech Team | Blitz Games Studios Ltd.<br> <br><br>-----Original Message-----<br>From: Eric Wing [mailto:[email protected]] <br>Sent: 03 March 2013 00:21<br>To: Daniel Varela<br>Cc: [email protected]<br> Subject: Re: [Openal] Race condition in some iOS devices.<br><br>On 3/1/13, Daniel Varela <[email protected]> wrote:<br>> Hello.<br> ><br>> As described in this link, there is a race condition in some iOS <br>> devices in which subsequent callings to pause resume over an OpenAL <br> > source voice does not works.<br>> Before we just fixed it by calling alSourcePlay twice when resuming <br>> the sound, but it causes the buffer to restart and we need to have <br> > several tracks synchronized for interactive music purposes and this <br>> solution is no longer valid.<br>><br>> I was wondering if someone has experienced the same issue.<br> ><br>> Thanks.<br>><br>> Daniel Varela | Audio Programmer<br>> Tech Team | Blitz Games Studios Ltd.<br>><br>><br><br>I filed that bug. I don't think it has been fixed. Please file a duplicate bug with Apple to raise the priority.<br> <br>Thanks,<br>Eric<br>--<br>Beginning iPhone Games Development<br>http://playcontrol.net/iphonegamebook/<br><BR /> <BR /> <font size="1"><br>***********<br>Blitz Games Studios Limited is registered in England (company no: 2482913) with registered office at Regent Square House, The Parade, Leamington Spa, Warwickshire, CV32 4NL, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error please send it back to us and immediately and permanently delete it from your system. Do not use, copy or disclose the information contained in this message or in any attachment. Please also note that transmission cannot be guaranteed to be secure or error-free.<br>***********</font><br><br><br><BR /> </body> </html> ------------MIME-890688297-1063364609-delim-- --===============1841785219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openal mailing list [email protected] http://opensource.creative.com/mailman/listinfo/openal --===============1841785219==--