JRiver Media Center 27.0.21 for Debian Buster (amd64, i386, arm64 and armhf)

More > JRiver Media Center 27 for Linux

<< < (4/5) > >>

wpballa:

--- Quote from: bob on October 15, 2020, 12:35:25 pm ---I don't see your Dragonfly in that alsacap list at all.

You aren't using pavucontrol to manage it are you?
IIRC that prevents other programs from using it outside of pulseaudio.

--- End quote ---
I removed pavucontrol, no change. Result of aplay -l shows it is there.
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: v15 [AudioQuest DragonFly Black v1.5], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 3: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 4: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 4: PCH [HDA Intel PCH], device 1: ALC887-VD Digital [ALC887-VD Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
It would appear that pulseaudio has taken over, but as I said, rhythmbox works just fine.

mwillems:
So in your earlier device listings, there's an error opening device 0; the later aplay lists device 0 as your dragonfly. That means that something (probably pulse audio, but possibly another audio program like rhythmbox or audacity) is opening the dragonfly for playback and preventing JRiver from taking exclusive control of the device.

As an experiment, try closing all open programs, and then setting your default sound output to something other than the dragonfly in your desktop sound settings panel (the panel you have a screen capture of above). If you then start JRiver can you see and play to the dragonfly hardware device?

If so, the issue in normal playback is that something is grabbing the dragonfly either directly or through pulseaudio. Your next test after that should be setting the dragon fly as the default audio device again, and then (with no other programs open) try setting JRiver to use the hardware device and try playing back. If you try to play then, JRiver should either play or error out with a sample rate error, in which case try setting JRiver to convert everything to 48KHz. If that doesn't work that means that pulse is grabbing exclusive access to the device and you'll need to set JRiver to play to the pulseaudio output rather than a hardware direct output if you want to keep using pulseaudio.

Contrarily, if JRiver works with a hardware output when nothing else open and the dragonfly is the default audio output in your desktop settings, then try opening your normal programs until it stops working and then you've got a hint about what's going wrong.

For context, I have had an issue where my web browser will sometimes (through pulse) open up a sink on my audio device even when no sound is playing through the browser. This effectively prevents JRiver from using a hardware direct output as long as the browser is open. So in that case the easiest thing is to set JRiver to use the pulseaudio output like everything else on the system, or if I want to use a hardware direct device for critical listening, I close my browser before starting playback. It might be something different for you, that's just an example.

wpballa:

--- Quote from: mwillems on October 15, 2020, 06:10:26 pm ---So in your earlier device listings, there's an error opening device 0; the later aplay lists device 0 as your dragonfly. That means that something (probably pulse audio, but possibly another audio program like rhythmbox or audacity) is opening the dragonfly for playback and preventing JRiver from taking exclusive control of the device.

As an experiment, try closing all open programs, and then setting your default sound output to something other than the dragonfly in your desktop sound settings panel (the panel you have a screen capture of above). If you then start JRiver can you see and play to the dragonfly hardware device?

If so, the issue in normal playback is that something is grabbing the dragonfly either directly or through pulseaudio. Your next test after that should be setting the dragon fly as the default audio device again, and then (with no other programs open) try setting JRiver to use the hardware device and try playing back. If you try to play then, JRiver should either play or error out with a sample rate error, in which case try setting JRiver to convert everything to 48KHz. If that doesn't work that means that pulse is grabbing exclusive access to the device and you'll need to set JRiver to play to the pulseaudio output rather than a hardware direct output if you want to keep using pulseaudio.

Contrarily, if JRiver works with a hardware output when nothing else open and the dragonfly is the default audio output in your desktop settings, then try opening your normal programs until it stops working and then you've got a hint about what's going wrong.

For context, I have had an issue where my web browser will sometimes (through pulse) open up a sink on my audio device even when no sound is playing through the browser. This effectively prevents JRiver from using a hardware direct output as long as the browser is open. So in that case the easiest thing is to set JRiver to use the pulseaudio output like everything else on the system, or if I want to use a hardware direct device for critical listening, I close my browser before starting playback. It might be something different for you, that's just an example.

--- End quote ---

OK, I got it working at 96kHz resampling. I'm suspecting that Zoom is stealing the resources and whether it works or not depends on the order I started JRiver and Zoom. I will see if I can confirm this - yes starting Zoom killed JRiver's output. Probably worth a FAQ entry.

wpballa:

--- Quote from: wpballa on October 15, 2020, 07:35:57 pm ---OK, I got it working at 96kHz resampling. I'm suspecting that Zoom is stealing the resources and whether it works or not depends on the order I started JRiver and Zoom. I will see if I can confirm this - yes starting Zoom killed JRiver's output. Probably worth a FAQ entry.

--- End quote ---
OK, I give up, it works but still only briefly before things quit. I need Zoom more than JRiver and Zoom and Rhythmbox seem to work fine together, so ...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version