search

rooneypark / naclports

Automatically exported from code.google.com/p/naclports
0 stars 0 forks source link

OpenALSoft port doesn't work as of Chrome/Pepper 20 #57

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Build & run openal-ogg example form naclports.

What is the expected output? What do you see instead?
Instead of music, there is either no sound, it plays just for a brief moment 
and then loops (in a buffer a fraction of a second long) or from the start so.
Output from Chromium:
[davorin@lumpy ~]$ chromium localhost:8000/openal_ogg.html
[28,737912576:20:41:34.222734] Native Client module will be loaded at base 
address 0x00007faf00000000
Audio devices available:
        PPAPI Output
        No Output
ogg file, channels: 1, rate: 44100
        num_samples: 1047467 buffer size: 2094934
AL lib: ppapi.c:95: buffer underrun
AL lib: ppapi.c:95: buffer underrun
AL lib: ppapi.c:95: buffer underrun

What version of the product are you using? On what operating system?
NaCl SDK/Pepper23, Chromium 23, Arch Linux

Please provide any additional information below.
I've fixed OpenALSoft patch from naclports to work perfectly (or at least so it 
seems).
I've removed additional thread that buffering data for OpenAL, I'm not sure 
what its purpose really was (maybe to handle the case when OpenAL sends dat to 
PPAPI faster/slower than it is processed? I don't see such mechanism in other 
OpenAL backends, so I guess OpenAL should handle that internally?).
Additionally it's ported to 1.14.

Patch for OpenALSoft 1.14
https://raw.github.com/ducakar/openzone/master/etc/patches/openal-soft-1.14.patc
h

p.s.
All my patches can be found here:
https://github.com/ducakar/openzone/tree/master/etc/patches

Except for SDL2 and PhysFS, all patches are based on those from naclports but 
ported to the latest versions of libraries. You are free to use them in 
naclports (I don't claim any copyrights).

Original issue reported on code.google.com by Davorin....@gmail.com on 28 Nov 2012 at 10:01

GoogleCodeExporter commented 9 years ago 
I have struggled with what seems to be this same bug, but my problem platform 
in Win7 x64, Chrome 23.  

Removing the extra thread and just calling aluMixData directly from the PPAPI 
callback worked for me on the Win7 and Mac versions of Chrome.  Thanks Davorin! 
 But I'd be very interested to hear why the threaded buffering might be 
necessary.

I've attached a patch for the version of openalsoft-1.13 which is currently in 
naclports.

Original comment by cgreb...@gmail.com on 8 Dec 2012 at 6:23

Attachments:

GoogleCodeExporter commented 9 years ago 
I updated OpenALSoft patch to 1.15, my previous link is not valid any more.

Original comment by Davorin....@gmail.com on 9 Dec 2012 at 6:21

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm afraid I fixed this issue without seeing this bug or your patches:

https://code.google.com/p/naclports/source/detail?r=699

In regards to the extra thread, I believe that the current recommendation is 
that
the PPAPI audio callback should do as little works as possible, so that is why
a seperate thread is used to do the possibly expensive job of mixing the audio
into a buffer.  Might be overkill, and your approach could be better, but we'd
need to do a bunch of testing on low end machines to measure the difference.

Original comment by sbc@google.com on 1 Feb 2013 at 5:56

GoogleCodeExporter commented 9 years ago 
Closing for now, please re-open if you still have problems, or if you want to 
update
the openal version in a separate patch.

Original comment by sbc@google.com on 1 Feb 2013 at 5:57

GoogleCodeExporter commented 9 years ago 
Also, if you would rather use git you can use our semi-official git mirror here:

http://git.chromium.org/gitweb/?p=external/naclports.git;a=summary

That way you can mantain you changes as forks on (say) github.

Original comment by sbc@google.com on 1 Feb 2013 at 5:59

GoogleCodeExporter commented 9 years ago 
Works for me, thanks!

Original comment by cgreb...@gmail.com on 10 Apr 2013 at 12:06