playSoundFile() issues

[Knute]

I've set up playSoundFile() to play on an event, but I get no sound.

The highlights work, as well as the sendAll command that fires before playSoundFile.

The command is: playSoundFile("/home/knute/waves/action/restore.wav")

I am in arch linux, and do have nas set up and running. And can even play that sound file thru the auplay command that nas installs. So what am I doing wrong?

[Vadi]

Probably nothing, I found Qt to be quite lacking with sound frameworks and cross-platformity. Just setup an os.execute instead of myself:

Code: [show] | [select all] lua

os.execute("gst-launch playbin uri=file:///home/vadi/Games/Mudlet/Offensive/sounds/" .. ofn.sounds[sound] .. " &")

requires gstreamer.

[MudManMike]

Sorry to bump such an old thread but it was the solution to me getting sound files to work on 3.0.0-delta. I was wondering if you had issues with lag while the file was playing Vadi? What I mean by lag is the client completely freezes while the sound file is playing. I've had to edit the sound files to be fairly short so that I don't miss out on anything important in combat or die lol. The code i'm using is:

Code: [show] | [select all] lua

os.execute("gst-launch-1.0 filesrc location=/home/mike/mudlet-data/Sounds/fire.mp3 ! mad ! alsasink")

playbin makes the sound file sound funny.

Seems I was missing the & character at the end of the os.execute().

Code: [show] | [select all] lua

os.execute("gst-launch-1.0 filesrc location=/home/mike/mudlet-data/Sounds/fire.mp3 ! mad ! alsasink&")

Everything seems to be working fine now.
Given enough time most of the time I end up answering my own questions lol.

[SlySven]

Yeah, the trailing & on a *nix shell script - which is what is being executed - is nearly always essential and it says "carry on and run this script in the background and get straight back to what you were doing"!. If it is absent the caller (the Mudlet application in this case) WAITS for the script to finish before it continues and that is NOT what is wanted for sound effects.

<aside>Of course for other types of actions that can be scripted this can be an issue if the script needs to interact with the user's terminal (on standard input, output or error "files") as in those circumstances the script is forcibly STOPPED (and gets a SIGTTIN or SIGTTOU) until it gets a SIGCONT and gets continued when it is brought back to the foreground...!</aside>