Print

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

[JHR]

The main question: how can 16 bit or 24 bit audio-only FLAC output from MC 31 show as "padded" when 24 bit movie audio output does not show as padded?

I've dug into many topics about output padding and MC, going back 10 years I think I understand it. When using WASAPI, 16 or 24 bit audio signals are sent to a device in a 32 bit envelope, padded with zeroes, because the receiving device doesn't accept native 16 or 24 bit audio. This is, therefore, only a communication issue and should result in bit-perfect music. That's the gist of many posts I've seen both here and elsewhere.

But on my new HT PC movies don't report this when playing from JR MC, only audio-only files report this message.

And if padding is completely transparent, and bit-perfect, why even tell the user about it at all? What purpose does it serve to know this?

This situation can be very confusing for those of us who don't live and breathe this stuff, and who just want decent stereo music as well as multichannel sound from movies in a more or less simple HT setup.

I've included background for those who have the issues I did setting things up. I searched this forum for more information, and a lot of it is scattered, so here's my current AVR friction log for those looking in the future. I apologize for the long post, but I included as much detail as I could.

TLDR: IMO don't use an M1/M2 Mac mini if you want multichannel movies through HDMI to an AVR system (see below for my issues with that). An Intel Pro 12 NUC (or newer) with Windows seems to be a good alternative, but the Intel HDMI audio drivers are a little weird (no ASIO for my equipment). If you have multi-channel issues with media playback like I did, and your AVR can actually handle stream processing (most can), then set MC audio output options to bitstreaming >> HDMI. You'll get great multi-channel output from movies, but your FLAC audio files end up being "padded" when played--which is weird.

Long friction log on HT PC and MC:
I recently moved from an M1 Mac mini to an Intel NUC 12 Pro as a home theater computer. I'm hooking up MC from Windows 11 through HDMI to a Yamaha 1085 AV receiver (latest 2023 firmware) and then out to a 2021 Sony Bravia A80J HD capable TV (latest 2023 firmware).

I'm using HDMI because it's the *only* way to hook up the AVR--no USB connection there (which I much prefer).  I'm using the WASAPI driver because there is no ASIO driver for my setup. The Windows NUC reports an Intel driver for the SONY TV as the sound output--I assume because it's the end of the HDMI output, and FWIW, Mac OS did the same thing. Why it's not the AVR I have no idea.

There are issues with the Intel sound driver for sure that make everything more difficult--not the least of which is that it doesn't show any multi-channel capability, unlike the Mac's midi setup. Sigh. 

As far as I can tell, all hardware elements of the system, including the cables, are up to spec and can accept 16 / 24 bit streams. The AV receiver is due for an upgrade, and I'm considering one, but I doubt new ones are more bit-depth capable than the Yamaha and ESS DAC it uses.

Why upgrade to an Windows box? Because on the M1 Mac, there were many issues with MC and the system itself.

Stability is the biggest one, and the system would just lose channels intermittently through the midi interface (so you play a movie and MC would switch to stereo for some unknown reason), or MC would need a restart to recognize the right output. Sleeping the Mac seems to make issues worse. 

But there's more problems for folks considering the M1 / M2. For example, MC and the Amazon music app would fight over the output even though neither were set to exclusive, music was all streamed at the same sample rate and bit depth because Apple doesn't support multiple rates through HDMI anymore (ugh), and every time I'd upgrade MC I had to remember to switch the output channels around in MC (because for some reason they're switched from defaults on MC and M1 hardware--but not on other programs though).

*None* of this was the case with my old 2012 Intel Mac Mini. And even though I kept it as long as possible (upgrading RAM and installing an SSD), those old computers are more or less insecure now since the OS can't be updated. They also had a separate digital output I could use for music if I really wanted to, but I didn't need to, because HDMI music was actually fine.

So: the problematic M1 mini is becoming my new music-centered MC controller in a totally and different and separate stereo system. With USB -->DAC output, I shouldn't have the HDMI driver or MIDI selection issues, and it's stereo-only.

The new Windows NUC 12 Pro behaves, well, like Windows (which I also run as an MC server), with one or two very weird glitches. First, I couldn't get multi-channel output at all "out of the box" with the Intel sound driver for my TV. Stereo only, and with different bit depths and the Direct Sound and WASAPI drivers I kept getting errors.

So after two solid days of trying to figure out what was going on, I turned on bitstreaming in MC options and "magically" multi channel audio from movies started working predictably, with MC reporting a direct connection and respecting the source number of channels and stream consistently. Hurray!

However, when I switch to playing music, I get the "direct connection" with "padded output" message from MC. It doesn't matter if the FLAC output file is 24 bit or 16 bit, it's still padded.

Can anyone tell me why, since the audio from MPEG / MKV streams is also 24 bit and not padded?   

PS--JRVR video looks great through MC, the NUC and TV, though I'm sure I don't have it fully optimized yet. But that's for another post

[eve]

So after two solid days of trying to figure out what was going on, I turned on bitstreaming in MC options and "magically" multi channel audio from movies started working predictably, with MC reporting a direct connection and respecting the source number of channels and stream consistently. Hurray!


That's because you're bitstreaming. MC isn't doing anything with the audio really when bitstreaming, it's just sending the encoded data to your receiver which is handling the decode process.

When you're working with a FLAC file, JRiver decodes it to PCM and sends that data to the reciever.In your case, your receiver seems to want a 32bit stream so that's what MC is doing.


You wont get ASIO with HDMI, I mean, you can do an ASIO4ALL type setup or whatever but ASIO and HDMI don't really make much sense together, you're only ever doing that when there is no alternative (software that demands ASIO).

[JHR]

{snipped}
When you're working with a FLAC file, JRiver decodes it to PCM and sends that data to the reciever.In your case, your receiver seems to want a 32bit stream so that's what MC is doing.
{snipped}

Thanks for your response. That makes a lot of sense, though it still leaves me wondering why MC "doesn't recommend" bitstreaming (it's turned off by default in audio options and that's the recommended state). Wouldn't you always want to bitstream in a typical multichannel AVR setup (I mean, isn't that what your bluray player or streamer does when it works through HDMI)?

It's also a bit incredible to me that my old Yamaha receiver is looking for a 32bit audio stream from FLACs when it accepts 24 bit streams directly for movies (and IIRC, 24 bits is industry standard for movie sound).

Is this a common occurrence in audio-only files? I've never actually seen a 32 bit audio stream that didn't come from a brand-new high-bit-depth recording device (like a Zoom F3 field recorder).

One day, I'd like to know why "non-bitstreamed" multichannel audio output doesn't work despite the claimed Intel driver / NUC capability, but that's another HT tech mystery that I don't care to track down at this point. Maybe some other day!

Thanks again!

[JimH]

An ordinary FLAC file is usually 44.1/16.  When MC decodes it, it has to give it to the DAC in whatever form the DAC supports.  That's what you're seeing.

[eve]

Thanks for your response. That makes a lot of sense, though it still leaves me wondering why MC "doesn't recommend" bitstreaming (it's turned off by default in audio options and that's the recommended state). Wouldn't you always want to bitstream in a typical multichannel AVR setup (I mean, isn't that what your bluray player or streamer does when it works through HDMI)?

It's also a bit incredible to me that my old Yamaha receiver is looking for a 32bit audio stream from FLACs when it accepts 24 bit streams directly for movies (and IIRC, 24 bits is industry standard for movie sound).

Is this a common occurrence in audio-only files? I've never actually seen a 32 bit audio stream that didn't come from a brand-new high-bit-depth recording device (like a Zoom F3 field recorder).

One day, I'd like to know why "non-bitstreamed" multichannel audio output doesn't work despite the claimed Intel driver / NUC capability, but that's another HT tech mystery that I don't care to track down at this point. Maybe some other day!

Thanks again!

Bitstreaming can be great, especially for some people's use cases. In terms of why you wouldn't want to bitstream? JRiver has an incredibly comprehensive and flexible audio stack. EQ, Room Correction, Up/Downmixing, *tons* of stuff. You can't 'alter' the audio signal with bitstreaming (you're handing your receiver the already encoded data), therefore it doesn't work.
As for multichannel PCM not working with Intel's driver? I've never seen that, they've usually been relatively reliable there for me but it's also been a number of years since I was seriously using HDMI for any audio related stuff.

[JHR]

Bitstreaming can be great, especially for some people's use cases. In terms of why you wouldn't want to bitstream? JRiver has an incredibly comprehensive and flexible audio stack. EQ, Room Correction, Up/Downmixing, *tons* of stuff. You can't 'alter' the audio signal with bitstreaming (you're handing your receiver the already encoded data), therefore it doesn't work.
As for multichannel PCM not working with Intel's driver? I've never seen that, they've usually been relatively reliable there for me but it's also been a number of years since I was seriously using HDMI for any audio related stuff.

Yes--JRiver's capabilities are marvelous, and I'll try to get everything working again when I update my AVR. For now, I'd rather have multi-channel capability and reliability than the flexibility I could have.

So I've just been happily bitstreaming from JRiver for home theatre and music. If I shut down the computer when I'm done, it will start back up and work. But if I leave it on say, overnight, it will be in an unpredictable state (won't play mutlichannel, or won't play stereo music) when I return. Frustrating but workable.

As for going through the Intel driver (not bitstreaming), I don't know what's going on there. The few times I've been able to get it to work, it doesn't last, and seems unpredictable. For example, coming out of a sleep state particularly (but not exclusively lol) the driver seems to forget its multi-channel settings. I have no idea why, and I'm on the latest WIN11 drivers, etc. It might be losing the HDMI output capabilities when the TV sleeps? Hard to diagnose this one.

[JimH]

... if I leave it on say, overnight, it will be in an unpredictable state (won't play mutlichannel, or won't play stereo music) when I return. Frustrating but workable.

That's a common problem with HDMI.  Try a Google search for EDID problems.  There are devices that can solve it.

[JHR]

That's a common problem with HDMI.  Try a Google search for EDID problems.  There are devices that can solve it.

Thanks Jim for the pointer. I've recently upgraded my Yamaha AVR to a new Marantz (Cinema 40) and a lot of the issues have vanished (MC recognizes the Marantz as output, Windows seems to like it better, and some other things "just work").

But I'm still having trouble with coming out of sleep and the HDMI channel, so I'll definitely check on the EDID issues.