I can confirm DarkElevenAngel's method works when not in the desktop (to exit use CTRL-ALT-F2 and login) That is due to my lack of time and my unfamiliarity with how to use the Alsa stack properly. The Pi is able to reconnect with the car on boot so as far as that goes I have no issues it's just streaming audio over. It's just a matter or having access and time with the car to test my theory for Bluetooth. I've been able to get omxplayer to play directly to my USB speaker not in my original setup,that can be found here viewtopic.php?f=28&t=214920 I had some issues with my display as well as Bluetooth. Sorry I missed this, I assume you're referring to the pixel desktop, I'm working strictly from the command line. It seems applications, like Kodi, do not necessarily use the Linux system defined output device but can choose their own. This is where my knowledge runs a bit thin. Once the BT device is both paired and connected then it is a matter of getting a Linux system to build an audio route from application to device. With the device paired and connected you should be able to get sound out of your browser, for example YouTube. That is step 3 in the link you used from the CLI. Can you verify that you have a Bluetooth connection to your device - from the GUI right clicking the 'audio' icon should allow you to connect the BT device. So let's take your problem in stages.īluetooth has two stages to getting devices operational - first pairing, and then connection. LD_PRELOAD=/usr/lib/libGL.The stock Raspbian should be able to pair Bluetooth devices and get an audio connection established that gets your audio out to the speaker, which was the state I got to in my post above. For now, I have shortcuts in Kodi Favorites and working audio. To get around this I hardcoded the options, which is not a long term solution becasue this might be overwritten with a future update. Which is a problem if you need to use a custom audio device to get sound. But in this case all the chrome_OPTS variables are not loaded. Thus the chrome-start of your add-on is called on opening of a url. As I found out if you use a custom path to Chrome, which is needed with your Chrome addon, the script.sh is completely skipped. So I started to check the chrome-launcher files to see if I could find a starting point to begin fixing this. I have tested the live-usb, no audio when used on my NUC. If not, it probably has to do with the custom audio. I'm going to run this live-usb on my NUC tonight to see if it works. I have it running now on my laptop (live usb) which does have an analog output, I made no custom config or script changes. Maybe I should to try to stop and start pulseaudio like it is in /storage/.kodi/addons/browser.chrome/bin/chrome-start. So I select the actual Chrome location, thus al the tweaks in chrome-start are not carried over. So I have to manualy tell it where it is, but /storage/.kodi/addons/browser.chrome/bin/chrome-start is not recognised as chrome. I think the problem lies in the Chrome-launcher addon, it does not recognize the location of Google-Chrome. If I am correct, the value that I put in the custom audio field is directly loaded in the $ALSA_DEVICE variable. But when I use Chrome-launcher these options seem to be overriden. These options get loaded when /storage/.kodi/addons/browser.chrome/bin/chrome-start is started. It is the custom audio option of the CHrome add-on settings.
0 Comments
Leave a Reply. |