[timdog82001]

It would really add a lot of flexibility to the audio aspect of the skinning engine if skinners were able to specify a particular media file to play as a gui media file, meaning it wouldn't show up in playlists, wouldn't interupt currently playing media, and the user wouldn't be able to go to the visualization screen. It would behave the same as the navigation sounds. It could possibly be achieved like this:

XBMC.PlayMedia(gui,Q:/skin/MediaStream/sounds/filename.mp3)

it would be gui as it is here if you want it to play as a gui sound, and perhaps notgui for regular playback.

It would be great if this could be implemented for audio and video as well, allowing use of a video window, but let's go one step at a time..



If implemented right, maybe this could make the feature requested in this http://trac.xbmc.org/ticket/5401 (background audio) possible as well, perhaps with the addition of a <loop> tag for the media, something like

<onfocus>XBMC.PlayMedia([not]gui,[not]loop,Q:/skin/MediaStream/sounds/filename.mp3)</onfocus>

That should allow one to set it so that upon loading the skin it would automatically begin looping the ambient audio and (hopefully) resume automatically after stopping playback of other media

[althekiller]

The players are too tightly bound to the application as the code sits today. There can only be one player running at any time. Alleviating this is no small task, but I wouldn't hold my breath.

[timdog82001]

darn, well thanks for responding

[timdog82001]

I have a perhaps better idea of how it could be used, perhaps an additional tag for all controls with a conditional. Something like...

<control type="image" id="14">
<texture>wef.png</texture>
<sound condition="Control(14).IsVisible" loop="false" delay="0">Q:/skin/Mediastream/sounds/filename.wav<sound>
</control>

Perhaps by default it would automatically play when that control becomes visible, but the conditional would allow you to make it play it other times, such as when it gains focus, when a window opens, etc.

I think it would be more flexible that way allowing you to do things like link audio sounds with animations.

Anyway, I imagine this doesn't change what you said about players being tightly bound and such, but is there any reason not to submit a feature request to trac in the hope that some future dev might see it and feel inspired and decide to implement something along these lines?

EDIT: I should mention again, i still intend that this would be a gui sound in nature

[Gamester17]

The players are too tightly bound to the application as the code sits today. There can only be one player running at any time. Alleviating this is no small task, but I wouldn't hold my breath.

Actually, there is already a patch on trac for using multiple players simultaneously, however it has not yet been accepted because of its design, see => http://trac.xbmc.org/ticket/4267

I don't like the way the rendermanager is moved into the player. The render manager should be extended to support multiple renderers, or it should be possible to have multiple instances of the render manager.

If someone could submit a patch that changes that in an acceptable way then it might be added to XBMC SVN.

[timdog82001]

Nice, good to hear. Hopefully somebody with the know-how is interested enough in that to take a look at it.