Hello everyone,
as the title says, I am unable to get Openhab to playback live audio from a stream online (https://liveradio.swr.de/sw282p3/swr3/play.mp3). It works fine when streaming it to a Google Home mini and also playing back the barking.mp3 file works for the web audio, but the combination of both is not working :D. I am using openhabian in its current version on an RP4. I do not get any error messages in my logs, just get told the rule which triggers the web audio is running. The stream is working fine when I manually play it in those browsers. I have opened mainUI, Habpanel, etc. on an ancient iPad2, an android tablet, and a windows 11 pcā¦
Has anyone an idea what could be going on?
Thanks for any advice!
WEB audio so to play in your device running the WEB browser.
Note that you have an option to enable for Web audio either in Main UI or Basic UI. Did you enable it?
Your browser is run on what OS?
As the barking.mp3 is running fine on bothe devices i doubt it is the option, but where would i find it? Also both devices are running habpanel.
Its windows 11 with chrome and a Galaxy Tab s8 running the latest update, also chrome.
I just tested on Windows 10 with the console commands after enabling the option in Main UI (Firefox).
Only barking.mp3 is working. doorbell.mp3 is not working and any mp3 WEB radio I tried including your URL did not work.
Do yout know if it was working better in OH3 ?
@dalgwen : do you think the changes done in OH4 could have broken something with the WEB audio sink ?
I can confirm that, too. Firefox plays barking.mp3 in BasicUI, but not doorbell.mp3. Chrome and Edge play both.
Strangely, the Android App is playing neither - I thought it was also able to play webaudio, isnāt it?
It could be quite easily patched to work with openHAB as a proxy.
I did some test a while ago during this PR.
I was able to play a radio stream through the audio servlet to a chromecast binding. Should be straightforward to do this on the WebAudioAudioSink by deleting the test and lines 74- > 83.
At the time, it didnāt seems a good idea. But maybe for the webaudio sink, it is ?
One issue that will likely occur when it would work is that there is no way to make it stop streaming. It normally plays new audio simultaneously and doesnāt stop the currently playing audio.
We always have the possibility of converting audio. The pulseaudio audio sink does this to play MP3 to a PCM remote sink. But doing a workaround (and adding new dependency) for browser insufficiency is a shame.
I fully agree.
I just did a very simple test: I dropped both files in question (barking.mp3 and doorbell.mp3) on an empty Firefox window to see if it will play them. It played both this way. So it is not the files themselves which keep Firefox from playing doorbell.mp3. But Iām not familiar with the technical background, so I have no idea where to look further.
Yes, I can confirm that. But I also can confirm that Firefox seems to used different method for playing sound, wether directly or by the webaudio API. āDirectlyā, it works, and with the webaudio API we get :
The buffer passed to decodeAudioData contains an unknown content type.
A quick search on internet shows that we are not alone in this case. I really donāt know what is the root cause, the file or Firefox, but it seems outside of our scope. All that I can propose is a workaround : you can load the file with Audacity and export it as a MP3, and this new file will work.
I just tested this method with the doorbell.mp3. It is OK and I will make a PR to replace the sound bundled with openhab with this reencoded one.
Indeed ! So I made two PRs for that yesterday (one for the webUI and one for the core)
I made the modification in the aforementioned core PR. But there is still a big issue : the webUI is not able to play an infinite stream. So it will work for all URLAudioStream that are finite (no more CORS issue), but still does not for webradio or live streaming.
Surprisingly, playing something in streaming mode seems difficult (but Iām not good with front end dev)
