USB input

[Rufus McDufus]

The USB INIT setting on the web interface may well just enable/disable udev (or whatever it is)  at the OS level. I do tend to dive in in the command line without actually seeing whether the setting is available through the web interface/GUI

[edit] On Volumio it took a bit of figuring but udev is/was disabled in the orion_optimize.sh script, part of the Volumio customisations. See here -
https://volumio.org/forum/usb-dac-hotplug-t2515.html

[Soniclife]

Yes, USB INIT is on as per default. What do you have streaming to your Pi?

I have my music on a NAS and rune audio pulls it from there. It's a Pi2 if that matters. I can turn my devialet on and off, swap inputs and never have to reboot the Pi. I get the same when I use volumino. It would drive me crazy if I had to reboot all the time.



Sent from my Nexus 5 using Tapatalk

[AllenB]

Yes, USB INIT is on as per default. What do you have streaming to your Pi?

I have my music on a NAS and rune audio pulls it from there. It's a Pi2 if that matters. I can turn my devialet on and off, swap inputs and never have to reboot the Pi. I get the same when I use volumino. It would drive me crazy if I had to reboot all the time.



Sent from my Nexus 5 using Tapatalk

I was wondering how you had Roon working through your Pi, and then you mentioned Volumio which presumably sets itself up as a music player on the Pi and, therefore is picked up by Roon. Roon will be releasing an image for Pi (and other slim devices I believe) when they release RoonBridge into the wild, but until then I have been using the HQP integration with Roon that plays via the HQP NAA on the Pi.

But my issue is with HQP's little network daemon NAA, which is not clever enough to know when the USB connection is alive or not. OK if the service starts with the USB connection live, but when that is changed (Dev sleeping or input switched) the NAA drops the connection, and you have to reboot it each time. Really not good in my book, but Jussi at HQP seems to ignore the issue, because it is not the way he uses his system, his whole system is either on or off, and you have to go through a certain sequence. What a phaff!

I suspect this is the same with other Linux based slim devices such as Cubox, SoSE when used with Dev's. It's probably a USB bus characteristic of Linux, but really, really annoying when all you want is to listen to music. I can deal with the reboots, but I can't expect other members of the family to cope with it.

[Hifi_swlon]

I was wondering how you had Roon working through your Pi, and then you mentioned Volumio which presumably sets itself up as a music player on the Pi and, therefore is picked up by Roon. Roon will be releasing an image for Pi (and other slim devices I believe) when they release RoonBridge into the wild, but until then I have been using the HQP integration with Roon that plays via the HQP NAA on the Pi.

As far as I know, the only thing that will work on the Pi as a Roon endpoint right now is a squeezebox type emulator.

But my issue is with HQP's little network daemon NAA, which is not clever enough to know when the USB connection is alive or not. OK if the service starts with the USB connection live, but when that is changed (Dev sleeping or input switched) the NAA drops the connection, and you have to reboot it each time. Really not good in my book, but Jussi at HQP seems to ignore the issue, because it is not the way he uses his system, his whole system is either on or off, and you have to go through a certain sequence. What a phaff!

I suspect this is the same with other Linux based slim devices such as Cubox, SoSE when used with Dev's. It's probably a USB bus characteristic of Linux, but really, really annoying when all you want is to listen to music. I can deal with the reboots, but I can't expect other members of the family to cope with it.

I've seen a few exchanges between Jussi and his customers over the past year since I first started experimenting (albeit briefly) with HQPlayer. I don't want to be mean because I think he's a passionate guy very skilled in his specialisation, but I think its fair to say he's not as customer facing as the Roon guys (who is I suppose). I get the impression he kind of writes it for himself, and lets others use it - and as long as they're happy with the way to works it OK, but if not…..

The impression I got from any discussion with the Roon guys is that their code will re-establish connection on any platform and shouldn't be OS dependent. Have you tried to the RoonReady mode on your OrbiterSE to see if that works? Your probably one of the first to be able to try it….

[AllenB]

OK I think I misconstrued Soniclifes' post, and though it was an auto-correct error, but he is using Rune Audio, another music player for various platforms. Might try that on my Pi 2.

[AllenB]

I was wondering how you had Roon working through your Pi, and then you mentioned Volumio which presumably sets itself up as a music player on the Pi and, therefore is picked up by Roon. Roon will be releasing an image for Pi (and other slim devices I believe) when they release RoonBridge into the wild, but until then I have been using the HQP integration with Roon that plays via the HQP NAA on the Pi.

As far as I know, the only thing that will work on the Pi as a Roon endpoint right now is a squeezebox type emulator.

But my issue is with HQP's little network daemon NAA, which is not clever enough to know when the USB connection is alive or not. OK if the service starts with the USB connection live, but when that is changed (Dev sleeping or input switched) the NAA drops the connection, and you have to reboot it each time. Really not good in my book, but Jussi at HQP seems to ignore the issue, because it is not the way he uses his system, his whole system is either on or off, and you have to go through a certain sequence. What a phaff!

I suspect this is the same with other Linux based slim devices such as Cubox, SoSE when used with Dev's. It's probably a USB bus characteristic of Linux, but really, really annoying when all you want is to listen to music. I can deal with the reboots, but I can't expect other members of the family to cope with it.

I've seen a few exchanges between Jussi and his 'customers' over the past year since I first started experimenting (albeit briefly) with HQPlayer. I don't want to be mean because I think he's a passionate guy very skilled in his specialisation, but I think its fair to say he's not as customer facing as the Roon guys (who is I suppose).  I get the impression he kind of writes it for himself, and lets others use it - and as long as they're happy with the way to works it OK, but if not…..

The impression I got from any discussion with the Roon guys is that their code will re-establish connection on any platform and shouldn't be OS dependent.  Have you tried to the RoonReady mode on your OrbiterSE to see if that works? Your probably one of the first to be able to try it….

Yes, I am not trying to put Jussi down or anything, he has built a very dedicated following for his software that he so passionately believes in. It sounds terrific, and he will sort out issues that arise quickly, I just believe he does not see this as an issue, you accept his NAA as it is.

So for me, my Dev and Roon are not going anywhere, and I can just as easily use a Roon Ready slim device and not have this issue. It is such a shame though, as it looks like I will have to forego HQP NAA in this set up. Roll on when Roon build in their own DSP enhancer!!

[Hifi_swlon]

So for me, my Dev and Roon are not going anywhere, and I can just as easily use a Roon Ready slim device and not have this issue. It is such a shame though, as it looks like I will have to forego HQP NAA in this set up. Roll on when Roon build in their own DSP enhancer!!

I get the impression this is now pretty high on their list. My guess is advanced DSP and room correction in the next couple of releases after 1.2, but that could still be a fair while, and may or may not be better than HQ Player. I honestly couldn't tell the difference when I tried it, but I think my room issues probably overshadow any benefit, and it just seemed like too much hassle top be honest. I dont want to put all my eggs in one basket, but in this case i'll be more than happy if Roon incorporates room correction and radio - that would be me done and happy with single interface for everything.

[AllenB]

Yep, I desperately would like iRadio and hopefully, it might make it into Roon 1.2, but I suspect it will follow. DSP enhancer & room correction are on the list I believe, even if they became top-priority after 1.2, I would not expect it until towards the end of this year.

So for general usage (by family as well) it is going to have to be Roon, sans-HQP, the latter being kept purely for my nerdy tinkering and listening sessions when i want to upsample. Shame really, because HQP does a very nice job of upsampling lesser quality streams (AAC, Tidal Premium, etc) to DoP on the Dev.

[Soniclife]

OK I think I misconstrued Soniclifes' post, and though it was an auto-correct error, but he is using Rune Audio, another music player for various platforms. Might try that on my Pi 2.

Ha, yes two similar products with similar names, no chance of confusion.

As far as I understand it squeeze box emulation is the currently best way to get roon to work with a Pi. I'm hoping roon release their own image soon, then I'll try it.

[ismarketing]

Having these same issues using Squeezelite to feed a new Micro Rendu into Dev 120.  I need to reboot the Rendu each time I want to listen.

The designer of the Rendu suggested a HIface 2 USB-SPDIF adapter could mix the issue.  I have one coming tomorrow and will report back.

Any insights on whether these problems trace back to the Dev or the playback software?  People running Roon into the Micro Rendu into the Dev seem to n ot have issues.

Thanks