Print

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

[Jim_F]

You know, this **almost** works.  If I "enable DLNA" in MC (either
"Generic DLNA" with "Format: PCM 24-bit" or else just "Audiophile 24-bit DAC")
and then "Open Live..." to get a "Loopback" entry in MC's playlist
for a default Windows (64-bit Win7) playback device which is
outputting 24/192 audio (while the output device selected for
MC itself is "Null Output"), then the signal shows up fine in MC's
"spectrum analyzer" display and elapsed-time counter, and
it's **also being streamed**, because, using the foobar2000 UPnP/DLNA
client's UPnP browser, the MC DLNA server shows up, and I can
select "Playlists->Recent Playing Now's" and get "Loopback" into
foobar's UPnP Browser Selection playlist.

Only trouble is, when I try to play the "file", foobar doesn't
have enough information to do so.  It shows up briefly at the
bottom of the window as "PCM | ? kbps | ? Hz | N/A? | 0:00"
and then I get the error message:

Unable to open item for playback (Unsupported file format):
"live://loopback"

Now if I play a 24/192 wav file directly in MC, and grab the
DLNA stream in foobar, then foobar has all the information
it needs to play:  "PCM | 9216 kbps | 192000 Hz | stereo | 0:33 / 5:09"
etc.

It strikes me that if I could just right-click the "Loopback" entry
in MC's playlist and edit some of those tags (which are populated as
expected when MC is playing a local file) --

Bit Depth
Bitrate
Channels
File Type
Sample Rate

-- then, assuming that information is streamed by MC's DLNA
server (as "Filename" clearly is being streamed), then one might actually
be able to play the Loopback playlist entry, via MC's DLNA server,
in foobar's (or some other) DLNA client.

(As a matter of fact, "File Type" **is** an editable tag,
but the rest of the tags listed above are not.)

This could be an interesting feature to have, if it's as
close to being realizable as it looks on the surface.

[Jim_F]

I actually figured out a way to do this (sort of), in case anybody's interested.

There's a free package of VST plugins ("ReaPlugs") published by the folks
(Cockos) who sell the "Reaper" multitrack Digital Audio Workstation, one of which
is called ReaStream.

This VST plugin (hosted by Reaper or any other audio application
capable of hosting VST plugins, such as MC) will send audio over
the network to another instance of itself hosted by another VST
hosting application (the network traffic can be restricted to a single
machine if you choose "local broadcast" in ReaStream).

So it turns out that you can use ReaStream as the last VST plugin
in MC's DSP Studio to send a stream to another instance of
ReaStream hosted as a VST plugin by foobar2000.  (I'm using
foobar2000 v1.3.11 together with ReaStream hosted by
George Yohng's VST wrapper ver. 1.2 for the experiment.).  And it works,
at least for foo_upnp's PSC (Playback Stream Capture) output, which can
be played in another instance of foobar (or in HQPlayer, for that matter), by
playing from location "http://<ip address>:<port #>/content/psc.wav"

There's an unusual wrinkle with such a setup -- the destination instance
of ReaStream (in foobar, let's say) will not, itself, "push" audio
through the playback chain.  So you have to use a trick (described at
http://forum.cockos.com/showpost.php?p=1216728&postcount=26 ) --
you play back digital silence (in foobar, Add Location silence://100000
gives you a day and almost four hours of it -- at 44.1 kHz), and this gets **mixed**
with the audio coming in from the ReaStream plugin.  That entails
another wrinkle -- if the audio coming in through ReaStream has a
sample rate greater than 44.1k, then you have to upsample the
digital silence ahead of ReaStream. (At least you don't have to worry
about the quality of the upsampler generating zeroes at a higher rate).

If you're streaming PSC from foobar via the foo_upnp plugin, then
any DSP plugins you're using (resampler, ReaStream) need to be inserted
into foobar's main DSP chain.  To get a stream to a DLNA client, DSP plugins
would go in the DLNA server's DSP chain, much as with MC's DSP Studio.
However, from what I've seen (heard) so far, this
kludge does not work as well (or at all, really) with a DLNA client as it does with
a PSC client.  In DLNA server/client mode, there is sound, but playback is choppy
and unusable.  But I can certainly stream PSC to HQPlayer on a second machine
(streaming in turn to Miska's  Network Audio Daemon on a third
machine).

I'm kind of amazed that the buffering and flow control work well
enough for this kind of audio chain to be usable at all (in my experiments,
I have the final audio playback devices in both MC and the instance
of foobar it's streaming to set to NULL).

So here's a blast from the past.  As I type this, I'm listening to
foobar 0.8.3 playing back WavPacked float-32/44.1 kHz files -- ripped
Redbook CD's processed through Hans van Zutphen's "Perfect Declipper"
VST plugin in a Sound Forge batch that starts by widening the files
to 32-bit float and ends with peak-normalization to -1.03 dB
(which seems to be enough to prevent intersample clipping when upsampling);
I just save  the 32-bit outputs of the Sound Forge batch and dither
them to 24-bit fixed-point in real-time during playback -- being upsampled
to 192 kHz by the (in)famous Sample Rate Converter That Must Not Be Named
(Lepus not into temptation), then being sent (still as 32-bit float), via one of
Otachan's old foobar 0.8.3 ASIO output plugins (a .exe version rather than a .dll,
to take advantage of a multicore processor) directly to the MC ASIO driver,
which causes, at start of playback, MC to pop up playing the "Ipc" entry
in its playlist.  I've got two VST plugins active in MC's DSP Studio --
iZotope Ozone 4 MBIT+ dithering to 24 bits (a bit superfluous, but
there it is) and then ReaStream.  On the same machine is another
instance of foobar (v1.3.11) playing digital silence at 192kHz and
picking up the audio from MC via its own ReaStream VST plugin.
The second foobar's foo_upnp server plugin streams PSC-format 24/192
to HQPlayer (on a second machine), upsampling to DSD512 (it's a Skylake
machine with HQPlayer using CUDA offloading to an nVidia GTX-1070),
in turn sending native DSD to the Network Audio Daemon
on a third machine, and then out via USB to an iFi iDSD micro DAC.
The two sides of the (wired) network triangle (with HQPlayer at the apex)
are independent (from each other, and from the internet) network segments.
All three machines are Fidelized and Process Lasso'd.

With my usual setup (a single instance of foobar 1.3.11 on the source
machine streaming PSC to HQPlayer), things are pretty solid (hiccup-wise).
With the foobar 0.8.3-->MC-->foobar 1.3.11 kludge, quite surprisingly, things
are **almost** (but not quite) as solid.  Maybe I could get away with something like
that long-term if I had a bit more horsepower on the source machine
(which is already a quad-core i7 loaded to about 10% by all this nonsense, though
one core -- the one running foobar 0.8.3 -- is consistently loaded
to 30-50%).  Or maybe there are in fact artifacts of buffering/flow control that
make the occasional hiccup inevitable.  I'd be curious to try this on
a more powerful machine to see.

What is the use of such a kludge?  I dunno -- streaming analog sources through
an A/D converter into a sound card via MC's live input to a remote system?
I'm sure people can think of things.

There are other methods of linking together these players, but none
of them are "high resolution" (i.e., >16 bits and >44.1 or 48 kHz).
Some of this may be for political and/or ideological reasons -- the notion
of "high resolution audio" (i.e., better than Redbook CD standard)
is dismissed with scorn on some forums popular with, e.g.,
foobar plugin authors.  (Never mind the notion of "upsampling" ordinary
Redbook to >16 bits and >44.1 kHz, or to DSD -- "You can't create
information that wasn't there in the first place!  It's just a waste
of bandwidth, processing power, and electricity!" they'll screech.)
So foobar can do "live input" with foo_record,
but only at 16 bits/44.1 kHz.  "Stream What You Hear" works great -- at
up to 16 bits/48k Hz.  FFmpeg can stream from a capture device
using the DirectShow interface -- limited, it seems, to 16 bits/44.1 kHz.
VLC (based on FFmpeg) sure **looks** like it can do anything.
I think I once got it to stream MP3 over HTTP to foobar.  And so on.
This is on Windows, with pre-built binaries.  I've never investigated
the world of roll-your-own software under Linux.

[AndrewFG]

Gulp..

[Jim_F]

> What is the use of such a kludge?  I dunno -- streaming analog sources through
> an A/D converter into a sound card via MC's live input to a remote system?

Reflecting on this in more detail, I can see one glaring problem with any
such arrangement.

In the case of any software player taking its input from a file, there's
only one clock in the whole playback chain -- the one in the output D/A
converter.  Everything upstream from that only has one task -- to keep
its output buffer full without overflowing it.  This is an asynchronous
process; there's STOP/GO flow control all along the way, and as long as the
upstream processing is fast enough and the software is doing its job
correctly, there's no reason for there to be skips (buffer overflows)
or dropouts (buffer underruns) in the audio output from the DAC at
the end of the chain.

But having **two** clocks in the chain -- say, one in an input A/D
converter and another in the output D/A converter -- is a whole different
can of worms.  Even if the two clocks happen to be well-matched,
if they are freewheeling against each other there will inevitably
be eventual glitches in the audio output.  To prevent this, at the very least
you'd need a master clock to which both the input A/D and the output D/A could
be slaved, in order to lock them synchronously together.
(Though the Genesis Digital Lens from 20 years ago tried to accomplish
something similar, without a single master clock, by allocating a buffer according to
the relative rates of an input clock recovered from the S/PDIF
output from a CD transport and the Lens' own internal output clock, and periodically
reallocating the buffer during the silence between tracks; a few years later,
Asynchronous Sample Rate Converter chips -- CS8420, SRC4192, and the like --
could, somewhat controversially, be used to "glue" together separate
input and output clocks by actually resampling the audio data on the fly.
The ReClock software for playing movies does something similar to
what an ASRC chip does, by slaving the audio sample rate to a video card's clock.)

Even with synchronized clocks at input and output, the ideal buffer management
strategy would likely need to be different -- the input device could
not be told to stop or slow down; I imagine you'd want buffers filled to
a mid-point, rather than to the top.

No, it's not a simple problem, if you need to guarantee totally glitch-free
playback.  You might think 100% glitch free isn't necessarily a requirement,
but for me, even if there's only an audible glitch every few minutes,
I find myself tensing up in anticipation of the next glitch rather than
relaxing into the music, and it becomes more and more irritating
the more I listen.