thx and no it’s not pulseaudio itself it is the mplayer that takes around 2 secs to stat up till it starts playing the audio file.
I’m still looking for another player that can stream over pulse but haven’t found one that is faster. Only my squeezeboxserver plays mp3 etc. almost instant and has only the delay of the pulseaudio, so around 40ms.
Do other people have similar experience with pulse or am I the only one?
This is my mycrof.conf
Default mpg123 works perfectly.
Ok thx and what do you mean by perfect? How fast du you hear the audio when you see the processed answer in the CLI (yellow one).
And you use pulse over tcp or rtp?
To be honest, never checked through the logs. But basically straight after the thinking visual is stopped.
For instance. Don’t look at the weather request as that is always a bit delayed. Have a look at the date and time request after that for instance.
But the Audio is directly played through the HDMI to the TV?
Yes indeed. You have something different?
I did a lot of linux/sound architecture research over the year aiming to make mycroftos feel snappy on a user use level. I think/hope to help you out with all the stuff I learned.
yes I use a mycroft instance as an LXC Container on Proxmox. In the living room there is a RPi connected to a soundbar over SPDIF acting as pulseaudio sink. Other containers like kodi or squeezeboxserver do also use the pulseaudio sink in the living room.
So therefore wav runs over paplay and mp3 over mplayer. The latency given by pulseaudio is only 40ms however as already described mplayer an paplay takes some time to launch ~2 seconds and therefore generate an necessary delay…
"play_wav_cmdline": "paplay -d alsa_output.platform-soc_sound.iec958-stereo %1"
"play_mp3_cmdline": "mplayer -ao pulse::alsa_output.platform-soc_sound.iec958-stereo %1"Ah, right! Now I am connecting the dots. It’s you from that other thread🤦♂️
Ok, reading back a bit. Will be back when I have another idea (or not)
Oh boy I found the problem.
Let me explain. Currently I’m developing a new skill and since I can’t always talk to Mycroft I use the CLI to enter my phrases that get processed.
I use the MobaXterm SSH Client to connect to the Mycroft instance and as default there is an X11 server activated once you connect to the system. Therefore when my mplayer plays the wav or mp3 from mycroft it first treys to open a window through the X11 and play the audio there till it detects that this is currently not possible (since it is not a video rather an audio file that does not need window to bee shown) and starts playing it.
This delay is around 2 secs. Yesterday I used with my phone to enter the CLI of mycroft and it immediately played the mp3 or wav file generated by mycroft. This helped me to narrow down the problem and now with deactivated X11 server it runs as quick as possible.
Glad you found it, because that sounds like one of those you loose your hair about en never find the solution😎
Can you try changing the mplayer command to something like “mplayer -novideo”?
Well, I spent an entire day only coming to this realization myself. I use mobaxterm with x11 forwarding so I can run pycharm and see video output from cameras and such. I had the same issue in addition to it magically setting volume to 0.
I really need x11 forwarding to work with mycroft. I see your solution was to just deactivate it, but have you successfully found something that would work otherwise?
I found if set it to automatically start on boot, it doesn’t get hung up on the x11 forwarding (makes sense). However, I’d like to not start it on boot…
nope since I don’t need the X11-forwarding it is all good for me.
ssh -Y? Run a local copy to do testing on?
I’m not very familiar with the -Y switch, but what I read is that it only enables trusted X11 forwarding and I’m not sure that would help.
I think ideally I’d find an audio player for mycroft to use that doesn’t try to spawn an X11 display, but I can work around it a number of ways (start as a service on boot or load up a separate non-X11 enabled ssh session just to start mycroft) The mycroft is going on a robot I’m building and I’m trying to get everything incorporated into a single SSH session running tmux with X11 forwarding enabled on it.
I think it would be helpful if somewhere in the documentation (at least maybe the audio troubleshooting section since that’s where the problem is noticed) to indicate that X11 forwarding in ssh causes problems, @gez-mycroft
not sure it belongs in the docs
using mplayer is a user modification, if mplayer requires a X server thats not really mycroft’s problem, it doesn’t feel right to use mplayer to play system sounds at all in the first place
I’m using whatever is stock on a linux build… not sure if its mplayer or mpg123.
sorry, i was reading previous posts and confused you with OP
if you are using the defaults then i agree it should be in the docs, but even better if we find a proper solution
I personally don’t know for a fact that the issue is exactly as the OP stated. I never would have expected an audio player to consider spawning a window when it doesn’t actually spawn one when run from command line, but I don’t know enough to come up with any other explanation. The only thing I saw in mpg123 command line arguments relating to windows is that it attempts to rename an xterm window with the name of the file being played, but I think you have to specify that argument for it to try to do so. I’m new to using X11 so there’s lots I don’t know about it.
All I can say at this point is that I am highly confident it’s X11 forwarding related.
