Permalink
Browse files

front: Added on option to use audio-sles plugin

  • Loading branch information...
Gillou68310
Gillou68310 committed Apr 27, 2015
1 parent bd43e6b commit ee012933acc41e259ac95a1a31ab2490ac3d7b77
View
@@ -318,11 +318,13 @@
<item>@string/audioPlugin_entryNone</item>
<item>@string/audioPlugin_entryNoneNoSpeedLimit</item>
<item>@string/audioPlugin_entrySdl</item>
<item>@string/audioPlugin_entrySles</item>
</string-array>
<string-array name="audioPlugin_values" translatable="false">
<item></item>
<item>nospeedlimit</item>
<item>libmupen64plus-audio-sdl.so</item>
<item>libmupen64plus-audio-sles.so</item>
</string-array>
<string name="audioPlugin_default" translatable="false">libmupen64plus-audio-sdl.so</string>
View
@@ -351,6 +351,7 @@
<string name="audioPlugin_entryNone">None (audio disabled)</string>
<string name="audioPlugin_entryNoneNoSpeedLimit">None-debug (audio disabled, no speed limit)</string>
<string name="audioPlugin_entrySdl">mupen64plus-audio-sdl, v2.0</string>
<string name="audioPlugin_entrySles">mupen64plus-audio-sles, v2.0</string>
<string name="audioBufferSize_title">Audio buffer size</string>
<string name="audioBufferSize_entry2048">Default</string>
@@ -62,6 +62,9 @@ public static void syncConfigFiles( GamePrefs game, UserPrefs user, AppData appD
mupen64plus_cfg.put( "Audio-SDL", "SWAP_CHANNELS", boolToTF( user.audioSwapChannels ) ); // Swaps left and right channels
mupen64plus_cfg.put( "Audio-SDL", "SECONDARY_BUFFER_SIZE", String.valueOf( user.audioSecondaryBufferSize ) ); // Size of secondary buffer in output samples. This is SDL's hardware buffer.
mupen64plus_cfg.put( "Audio-OpenSLES", "Version", "1.000000" ); // Mupen64Plus OpenSLES Audio Plugin config parameter version number
mupen64plus_cfg.put( "Audio-OpenSLES", "SWAP_CHANNELS", boolToTF( user.audioSwapChannels ) ); // Swaps left and right channels
mupen64plus_cfg.put( "Core", "Version", "1.010000" ); // Mupen64Plus Core config parameter set version number. Please don't change this version number.
mupen64plus_cfg.put( "Core", "OnScreenDisplay", "False" ); // Draw on-screen display if True, otherwise don't draw OSD
mupen64plus_cfg.put( "Core", "R4300Emulator", game.r4300Emulator ); // Use Pure Interpreter if 0, Cached Interpreter if 1, or Dynamic Recompiler if 2 or more
@@ -259,6 +259,7 @@ public AppData( Context context )
libraryExists( "ae-exports" ) &&
libraryExists( "ae-imports" ) &&
libraryExists( "mupen64plus-audio-sdl" ) &&
libraryExists( "mupen64plus-audio-sles" ) &&
libraryExists( "mupen64plus-core" ) &&
libraryExists( "mupen64plus-input-android" ) &&
libraryExists( "mupen64plus-rsp-hle" ) &&

4 comments on commit ee01293

@littleguy77

This comment has been minimized.

Show comment
Hide comment
@littleguy77

littleguy77 Apr 30, 2015

Member

@Gillou68310
This is working great on my Nexus 7! I can't believe you just wrote a new audio plugin while no one was looking :P

What are your long term plans for this? Do you plan to push it upstream and maintain it there, or just keep it as an android-only plugin (like video-gln64)? What are the TODOs before merging it to master?

You probably saw this discussion already, but FWIW I'll mention it again:
mupen64plus/mupen64plus-core#79
It would seem like this new audio-sles plugin would be a better starting point than audio-sdl if we were to use the @bsmiles32 new backend audio API. What are your thoughts?

Thanks again!

Member

littleguy77 replied Apr 30, 2015

@Gillou68310
This is working great on my Nexus 7! I can't believe you just wrote a new audio plugin while no one was looking :P

What are your long term plans for this? Do you plan to push it upstream and maintain it there, or just keep it as an android-only plugin (like video-gln64)? What are the TODOs before merging it to master?

You probably saw this discussion already, but FWIW I'll mention it again:
mupen64plus/mupen64plus-core#79
It would seem like this new audio-sles plugin would be a better starting point than audio-sdl if we were to use the @bsmiles32 new backend audio API. What are your thoughts?

Thanks again!

@Gillou68310

This comment has been minimized.

Show comment
Hide comment
@Gillou68310

Gillou68310 Apr 30, 2015

I can't believe you just wrote a new audio plugin while no one was looking :P

That's probably because I started working on it on monday :P

I don't think upstream devs will be interested in this plugin so I guess we can maintain it downstream.

I just made a new commit to the sles branch which adds support for resampling, config parameters and dynamic buffer allocation. I still need to add the config parameters to the GUI. If there's no regression compared to the last version then we can merge it to master.

It would seem like this new audio-sles plugin would be a better starting point than audio-sdl if we were to use the @bsmiles32 new backend audio API. What are your thoughts?

If the sles plugin is prouved to be better than the sdl plugin in all situations, is there any reason to keep it downstream?

Gillou68310 replied Apr 30, 2015

I can't believe you just wrote a new audio plugin while no one was looking :P

That's probably because I started working on it on monday :P

I don't think upstream devs will be interested in this plugin so I guess we can maintain it downstream.

I just made a new commit to the sles branch which adds support for resampling, config parameters and dynamic buffer allocation. I still need to add the config parameters to the GUI. If there's no regression compared to the last version then we can merge it to master.

It would seem like this new audio-sles plugin would be a better starting point than audio-sdl if we were to use the @bsmiles32 new backend audio API. What are your thoughts?

If the sles plugin is prouved to be better than the sdl plugin in all situations, is there any reason to keep it downstream?

@littleguy77

This comment has been minimized.

Show comment
Hide comment
@littleguy77

littleguy77 Apr 30, 2015

Member

If the sles plugin is prouved to be better than the sdl plugin in all situations, is there any reason to keep it downstream?

Probably not. At the very least audio-sles would be the new default. Might be good to retain audio-sdl for a while though for regression tests (particularly if the upstream audio plugin api is getting refactored/obsoleted).

Member

littleguy77 replied Apr 30, 2015

If the sles plugin is prouved to be better than the sdl plugin in all situations, is there any reason to keep it downstream?

Probably not. At the very least audio-sles would be the new default. Might be good to retain audio-sdl for a while though for regression tests (particularly if the upstream audio plugin api is getting refactored/obsoleted).

@Gillou68310

This comment has been minimized.

Show comment
Hide comment
@Gillou68310

Gillou68310 replied Apr 30, 2015

I agree ;-)

Please sign in to comment.