Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jjrr]

Hi JRiver staff, I saw this by CamillaDSP:
https://github.com/marcoevang/camilladsp-setrate

Is it possible for JRiver to support something like this?

I would love to feed JRiver a USB source and have all the great DSP applied to it.

I know about ASIO driver on Windows but I use Mac and Linux.

[mattkhan]

Some form of input support is a longstanding feature request on Linux/mac, it's not available at this time though.

[jjrr]

But since the RPi4 can do it, if JRiver could load some kind of firmware image onto the Pi4.

Then all of Windows, mac and Linux JRIver apps could "pull" audio from the Pi4.

Instead of making a virtual driver on macOS , make a fimware image that can go on Pi4

Then the desktop software 'pull's from the Pi4 firmware

And what I am talking about is something HQPlayer by Signalyst can already do, exactly in the way I wrote above.

Would be great for JRiver to offer similar...

[mattkhan]

Having an audio input on Linux, and presumably Mac, is not something that requires a custom firmware or anything like that. It just needs software support for an input in MC, unfortunately that appears to be tied to windows specific interfaces (wasapi loopback, asio, wdm) rather than something reusable with a pluggable interface layer and/or the os specific variant of that interface layer has not been prioritised hence does not exist.

[jjrr]

The point is to essentially have a hardware input

Then you don't need to have anything for macOS or Windows specific.

Less support issues with different OS

The hardware image is linux based and is proven to be working with camillaDSP and HQPlayer etc.

Then JRiver on Windows or macOS talk just to this firmware on RPi4 to pull in any stream.

The suggestion you make is exactly why nothing works on macOS still today, especially with automatic sample rate switching

Just in case you didn't understand... HQPlayer on macOS pulls stream from RPi4 - and thus supports automatic sample rate switching via the RPi4... And gets around macOS limitation.... the same limitation JRIver on macOS has in this regard

[mattkhan]

You seem to be missing my point but, in any case, it needs dev work so we can continue to wait for this functionality to be implemented

[jjrr]

You seem to be missing my point but, in any case, it needs dev work so we can continue to wait for this functionality to be implemented

Your point involves making a macOS virtual driver, like exists on Windows.

My point is it is not necessary to have a macOS virtual driver, to feed a USB source into macOS bitperfectly with auto sample rate switching.

If you understand what the RPi4 can do now since kernel v6.1 with it's USB-C OTG port, then JRiver on macOS can simply pull from the RPi4...

So the bulk dev work would be on the RPi4 (Linux obviously)

Minimal dev work on macOS - just pull the stream from the RPi4 firmware.

Will work with JRiver on macOS, Windows and Linux apps. It minimises work on the 3 operating systems.

[mattkhan]

Having to add another computer to the mix just to get an audio input is a rather strange approach.

[jjrr]

Having to add another computer to the mix just to get an audio input is a rather strange approach.

It is a headless (no interaction) firmware, as I mentioned a few times already.

No keyboard, monitor or mouse.

You burn an image and voila - the firmware appears as a USB DAC to any USB source.

Then the macOS or Windows app for HQPlayer simply pulls the stream - automatic sample rate switching & bit perfect being the key.

With one development, you can feed any source on macOS and Windows.

Hopefully this makes it easier to understand

You might call it 'strange' but it is a working solution right now.

More strange to still not have JRiver doing this on macOS after all these years - but here we have a great solution

[mattkhan]

Whether it's headless or not is irrelevant, having to run 2 computers just to get an audio input is a hack in my book. Certainly not something I would have any interest in anyway but each to their own.

The point is MC on Linux or Mac has no input capability whatsoever (except as a dlna renderer), if it gains that ability then feeding it with a stream from any connected device or software on the same host is easy on either os. There is zero need for any additional computer to achieve that, there is development in MC required.

Irrespective of how anyone wants it done, this has been requested for a long time to no avail so i would say it's reasonable to be pessimistic about it happening any time soon. We live in hope though

[jjrr]

A "hack" that is bit perfect and flawless seems better to me than something that will never come to macOS.

It is a CoreAudio limitation hence why it's never been done

As HQPlayer developer has figured out, working with Linux to be able to make it happen on macOS or Windows, seems the smarter solution that can work right now

Not in dreams about the future

[mattkhan]

sure, hacks can be good or bad and any working solution would be a step up from none.

It is a CoreAudio limitation hence why it's never been done

curious on this point, what is the limitation exactly on a mac?

[jjrr]

curious on this point, what is the limitation exactly on a mac?

Well if there was no COreAudio limitation you'd have similar functionality as the ASIO virtual driver on Windows available , on macOS already?

JRiver is not the only app that struggle with a virtual driver + automatic sample rate switching (the latter is the crux of the limitation)

BlackHole virtual driver exists but I don't know of any app that can use it with auto sample switching. You need to manually change sample rates in Audio MIDI.

The solution I detailed above skips CoreAudio completely for the input side of HQPlayer since HQP pulls the stream from the headless firmware box. Same would be true of JRiver on macOS or any of their OS.

[mattkhan]

you may want to raise that request explicitly on the main MC board (linking to whatever software provides that network audio stream)

[eve]

But since the RPi4 can do it, if JRiver could load some kind of firmware image onto the Pi4.

Then all of Windows, mac and Linux JRIver apps could "pull" audio from the Pi4.

Instead of making a virtual driver on macOS , make a fimware image that can go on Pi4

Then the desktop software 'pull's from the Pi4 firmware

And what I am talking about is something HQPlayer by Signalyst can already do, exactly in the way I wrote above.

Would be great for JRiver to offer similar...

It's doable but people would probably think it works for video which requires lower latency / synchronization than is really possible with tolerant, compatible RTP.

MacOS does support like AES67 and AVB very well with CoreAudio (in fact, Apple has had the plumbing there for AGES) so that's an avenue for you to explore.

I know what you're after, it's not really something JRiver is going to add.