Closed bahbarnett closed 7 years ago
Sorry, some clarity.
All runs were done with 2>&1 as well .. so, you will see some ALSA error messages included. EG,
ALSA lib conf.c:4858:(parse_args) Unknown parameter AES0 ALSA lib conf.c:4991:(snd_config_expand) Parse arguments error: No such file or directory ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM surround71:CARD=CK804,DEV=0,AES0=6,AES1=130,AES2=0,AES3=14
There are other options in my config file.. but, none of them have to do with audio. I have things such as 'fs=yes' and 'ontop' in there as well...
I suspect your device settings (i.e. this part audio-device=alsa/surround71:CARD=CK804,DEV=0
) are wrong (however, I'm not sure).
As you can see in my log, there are two different settings tried in the 5 runs.
And I used the LUA script mentioned, to easily find what seemed to be viable ALSA devices -- and tried every single one as config file options. None of them seemed to make one iota of difference.
It seems to me, that when I use this option in my config file: alsa-ignore-chmap
I should never see this: [ao/alsa] Asked for 8 channels, got 2 - fallback to stereo.
When using: audio-device=alsa/iec958:CARD=CK804,DEV=0
It shouldn't matter how many 'channels' the device reports for encoded streams. It's meaningless. The AMP does all of the decoding.
Shouldn't the above 2 + audio-spdif=truehd,dts-hd,ac3 result in SPDIF passthrough?
What am I missing here?
mplayer works and my amp reports a DTS / AC3 / whatever stream to decode. So this is technically doable with my current hardware and software setup.
Any ideas?
$ aplay -l List of PLAYBACK Hardware Devices card 0: CK804 [NVidia CK804], device 0: Intel ICH [NVidia CK804] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: CK804 [NVidia CK804], device 2: Intel ICH - IEC958 [NVidia CK804 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0
mplayer is using ao=alsa:device=hw=0.0, not device #2.
If anyone can suggest how to use alsa, and bypassing all of the remix / routing / asound pseudo devices listed -- instead just using the hardware directly? That seems to be what mplayer is doing in my case. And it works.
Note: S/PDIF doesn’t have enough bandwidth for TrueHD and DTS-HD MA, so of course enabling those options won’t help. You could only play the DTS core stream via passthrough, decode to stereo PCM, or transcode to AC3 using lavcac3enc.
I know I’m not being overly helpful here, but you could just get a receiver/amplifier with either HDMI or plain old RCA inputs. In general, all this passthrough business is more trouble than it’s worth. With HDMI, you could just decode everything to PCM without losing channels or sacrificing quality. And you won’t run into compatibility problems. (But you seem to have a fondness for very old hardware—isn’t that CK804 board more than 10 years old?)
Hmm.
I have an amp with HDMI inputs, Onkyo TX-NR646. However, lots of amps decode the HDMI stream, for example mine shows on-screen-display info when I monkey with the amp controls! It also boasts about being able to 'improve' the image.
No. Thanks. ... no thanks!
I can't even remotely imagine why someone would want an amp to decode, and then re-encode video after adding overlay info and monkeying around. Not only is there an entirely new chain of 'aw damn, what's gone wrong now', it irks me that one has to constantly upgrade the amp to support a newer form of HDMI.
My TV doesn't have an HDMI output -- which in the context of this conversation seems quite bizarre. In fact, it only has an optical output. Strange for a higher end model like an LG OLED.
And this guy seems to be in the same boat... with no one having any real resolution:
https://forum.kodi.tv/showthread.php?tid=311476
So basically:
OR
Sometimes, you just have to wonder what the point is :P
SPDIF can't do HD audio because SPDIF has no enough bandwidth, there's no political here. Not sure what exactly you try to achieve, and what exactly your setup is, and how exactly AV receivers degrade HDMI, but if your PC has 2 HDMI outputs (or HDMI+DVI, HDMI+DP) -- you could simply send video directly to TV from one HDMI, and sound (bitstream or multi-channel PCM) to receiver from another HDMI. mpv doesn't do what you want even when set to hw:0,0 like mplayer?
After yours and the above poster's suggestion, I tried HDMI. Raw pass through though -- I trust my amp to do a better job at decoding audio than lavcac3enc. And, even if not?
The less encoding/decoding that happens, the better. Fewer issues to arise.
Anyhow -- truehd + dts-hd are working now, as well as all audio. Mpv seems great, but a lot seems to have been sacrificed in the 'purge' from mplayer code, leaving a lot of edge cases out of luck.
Ah well. I get why, but it sucks that I was bitten by such an edge case.
I'm going to buy an el-cheap HDMI cable -- 50 feet. Should be fine for audio only... and see how that goes, without involving the amp in video.
It will unfortunately remove that second output from use (handy when debugging at the box locally), but what can one do?
As per your question? AV receivers have the potential to degrade the signal, because newer ones decode and encode the stream... and often after adding an overlay on top. Some users with some amps, have had issues with processing happening in the amp... instead of straight encode+decode. Sometimes by accident, sometimes to 'help' people.. with amps advertising 'improvements' to the picture.
Not to mention? More lag, courtesy of that post-processing happening ...
Great. :(
Long story short -- it's just not worth it, to slap an extra piece of hardware in the chain for zero real reason.
I guess I'll close this bug. It's not fixed, but I see zero interest in devs approaching this bug. Almost like they wanted nothing to do with it, heh.
Also thanks for the suggestions guys.
Mpv seems great, but a lot seems to have been sacrificed in the 'purge' from mplayer code, leaving a lot of edge cases out of luck.
Not sure what you mean. Like mplayer you can set the audio device directly.
All I know, is that I couldn't get any type of passthrough to work with my setup and mpv. Only PCM with my SPDIF. Yet it worked with mplayer.
I'm not blaming anyone in the larger scheme of things. I know a lot of mplayer code was legacy / etc. It just sucks that I'm one of the 'edge cases', for which all that baggage had a purpose.
And maybe I'm the last man on Earth trying to use spdif, heh. Certainly, it's not mainstream.. where as when I started to use it, it was the only way go get digital audio. HDMI wasn't even a consumer product at the time!
Hell .. this is my current motherboard for my media player -> https://www.anandtech.com/show/1552/2 .. that's right, released in early 2005. 12 years and going strong. Why?
Well, it works. And I have a spare. And what do you need CPU for? That's why I have a graphic card. (Of course, Nvidia has hosed me here, with vdpau sucking on HDR/10bit, and opengl not quite cutting it, but hopefully that will change).
I guess what I'm saying is -- you don't get everything.
But you know what I do get moving to mpv? Lots of little extras, like a cool LUA scripting interface. I used to have 4 separate scripts for mplayer, external wrappers and the like, to enable pause + resume, pop-up on screen with a list of full details about audio tracks, and more.
Yet, a few LUA scripts ... one I wrote, and 2 I downloaded? Done!
Anyhow, thanks devs. Hopefully I can get that second HDMI working for audio only. If so, I'm quite happy to spend $50 on a 50 foot cable, once every 15 years.
I trust my amp to do a better job at decoding audio than lavcac3enc.
lavcac3enc encodes audio to AC3, decoding is done by other libavcodec libs. And unlike with your receiver, it's actually possible to verify the bit-exact output of the software decoders.
As per your question? AV receivers have the potential to degrade the signal, because newer ones decode and encode the stream... and often after adding an overlay on top. Some users with some amps, have had issues with processing happening in the amp... instead of straight encode+decode. Sometimes by accident, sometimes to 'help' people.. with amps advertising 'improvements' to the picture.
Just to be clear: HDMI signals (at least <=4K) are not encoded (compressed) in anyway way, but transmitted as raw data. Yes, your receiver is able to modify the picture and add overlays, but if you turn off any "enhancements" the picture should be passed through 1:1, although possibly with a minimal delay.
I did indeed use the wrong lib name, but that doesn't change my point.
Extra encode/decode steps, any time the audio stream is monkeyed with -- adds a layer of potential bugs, issues and loss of quality.
Sure, you can verify it. So? Do you verify it each time? No one does. And bugs do happen, both in my amp's firmware and in various libs. But every step you add to a chain, increases the odds that bug will hit you.
Go ahead -- add 100 amps inline, encoding and decoding along the way. See how far you get before a bug hits you.
The same with HDMI. Encoding doesn't mean compressed -- and HDMI is indeed an encoded stream. And the stream is altered, when you add overlays and such on top. It's not 1:1 identical, it's having to reencode the stream from the ground up.
But all said and done, why do it. Why? Even if you find an amp that doesn't add overlays, and just passes the raw data through -- why bother? Why even add the extra step in the chain? To what end?
My last amp lasted 23 years -- yes years, and was an awesome piece of hardware. Why?
Well, because I didn't have to worry about buying a new one, simply because I changed my TV and my TV needs HDMI
Great. Let's spew more into the hands of corporate fat-cats, so they can buy more diamonds and fur coats for their simpering, scheming trophy wives who take all manner of pleasure in looking down their noses at us.
Their reconstructed noses!
There's not a thing real about them, which is why they want my HDMI data to be monkeyed with. It's a plot, I tell you, a plot.
And you.... YOU want to help them!
You dropped this:
In this thread, we learn that bandwidth is a political limitation, mpv is developed by big money capitalists, and plastic nose surgery coupled with thinly veiled sexism somehow plays a role in this.
Not everyone is conspiring against you. I mean the following in the least offensive way that I could possibly mean it: please talk to a professional psychiatrist to get checked for paranoid schizophrenia, if you haven't already. Things can get better.
On Montag, 30. Oktober 2017 18:50:11 CET bahbarnett wrote:
I did indeed use the wrong lib name, but that doesn't change my point.
Extra encode/decode steps, any time the audio stream is monkeyed with -- adds a layer of potential bugs, issues and loss of quality.
Sure, you can verify it. So? Do you verify it each time? No one does.
Actually, there are automated test suites for that reason.
And bugs do happen, both in my amp's firmware and in various libs. But every step you add to a chain, increases the odds that bug will hit you.
I’d rather think of it as removing extra steps. Takes less complicated monkeying around with bitstreaming (we do have to work around hardware bugs and quirks) when you just decode to PCM using a known-good decoder and send that to the receiver/amp. It reduces the chance of hitting firmware/decoder bugs in the receiver, too.
The same with HDMI. Encoding doesn't mean compressed -- and HDMI is indeed an encoded stream. And the stream is altered, when you add overlays and such on top. It's not 1:1 identical, it's having to reencode the stream from the ground up.
Actually it does this either way. But that doesn’t necessarily change the outcome. If no modification happens, the newly encoded output will be identical. That’s the point of using digital formats in the first place.
And don’t forget that S/PDIF has the same “problem,” and it even requires lossy compression for anything above 2 channels.
Well, because I didn't have to worry about buying a new one, simply because I changed my TV and my TV needs HDMI
next. Now, everyone has to upgrade their amp and TV in tandem. Great. Let's spew more into the hands of corporate fat-cats, so they can buy more diamonds and fur coats for their simpering, scheming trophy wives who take all manner of pleasure in looking down their noses at us.
Their reconstructed noses!
If that’s your problem, you could just pass analog signals to your amplifier. In fact, that’s what I would recommend anyway. Noise and distortion should not be a concern with balanced audio. Get a proper DAC for your PC, and use a balanced connection. I personally like stuff in the PA segment (rather than consumer market). Even the purely analog ones tend to have lower THD at volume levels that don’t make your head explode. And they’re often cheaper because they’re pure amplifiers that do nothing else. You actually get what you pay for.
There's not a thing real about them, which is why they want my HDMI data to be monkeyed with. It's a plot, I tell you, a plot.
And you.... YOU want to help them!
No we don’t. We’d actuall like to avoid having to deal with industry standards because they’re universally shitty. It’s just that sending PCM via HDMI is much easier to do reliably than all this bitstreaming mess, and certainly less crazy than having to transcode multi-channel formats to AC3 just so people with their ancient S/PDIF-only setups are happy.
It’s just that sending PCM via HDMI is much easier to do reliably than all this bitstreaming mess, and certainly less crazy than having to transcode multi-channel formats to AC3 just so people with their ancient S/PDIF-only setups are happy.
Besides, as I've noticed bitstream has issues with --display-resample
video synchronization (sound goes out of sync pretty soon).
But AFAIK Dolby Atmos still needs bitstream to an Atmos-capable receiver because Atmos works a bit different than "normal" Dolby/DTS (I'm not quite sure, though).
See? Horrible industry standards.
And here I'm, watching movies with the bultin stereo speakers of my TV and using my mobo realtek chip to listen to my computer audio paired with a 10yr old Philips headphone... SAD.
For the record I don't know/didn't analyze why spdif didn't work for the issue reporter. Probably some terrible ALSA mechanics, or he never tried to force the device that worked for him with mplayer. Anyway, normally mpv does support classic spdif.
@garoto if you're happy to live with it -- you're very lucky, because you have really saved yourself a whole lot of money...
@fhlfibh oh I'm satisfied yes, that rabbit hole is one I intentionally avoided. It didn't take much effort either. With food on the other hand...
OK -- an update.
After I tried HDMI -- my followup post stated that I'd next try fhlfibh's suggestion of a dedicated HDMI for video, and one for sound.
I'm going to document the steps required here, just to save others time. Even if the goal is not to run video to the TV, and audio to the amp, others may have other uses. EG, perhaps they want HDMI to an amp in another room, for audio only?
You'll need an active X session on the HDMI output you plan to use for audio. I don't think there's any way around this...
That active X session must remain active, or most likely your amp will disregard things (or X, or nvidia's drivers).
for things like lirc via inputdev, your video display must have control of the VT
I use nodm for my media center X session, so I added '-sharevts' to its /etc/default/nodm config file:
NODM_X_OPTIONS='-nolisten tcp -sharevts'
This ensures that the VT doesn't get stolen.. otherwise, the display goes blank (it's not active)
I also change the default VT for nodm, in the same file:
NODM_FIRST_VT=9
There are a lot of ways to do this, but we're talking about a dead X session here. No DM, nada running, and X is already root anyhow. It's just there to allow audio out.
This X session must have '-novtswitch', so that it won't change the active display on start/stop. I added to my crontab:
@reboot root (nohup startx -- :1 -config /etc/X11/xorg-SECOND.conf -nolisten tcp -novtswitch -sharevts vt7 & )>/dev/null 2>&1
Left alone, the above X session will eventually blank, so turn off blanking and dpms:
# cat /root/.xsession
xset +dpms
xset dpms 0 0 0
xset s off
xterm
In each X config file (your default /etc/X11/xorg.conf and the 'second' one, as referenced above), ensure that you reference each card's busid:
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BusID "PCI:6:0:0"
EndSection
You can get this by just starting X. NVidia's driver will scan all available cards, and your X log (typically /var/log/Xorg.0.log) should show your devices and busids...
That should do it. After, you can use mpv's -audio-device=help, and try various HDMI audio outputs, until you hit paydirt...
@bahbarnett I don't know why audio over HDMI would require an active X session. On my system it happily goes without. Though I use the motherboard's HDMI for audio, maybe GPU's hole works differently. And even if it does require an active X session, I don't know why would not just start a second (fake) screen on the same X on the required audio-GPU.
A second screen, creates the potential for a window to open there. It's far easier to have an X session under a completely different user, rather than monkeying with window managers, and applications, to ensure they don't open on the wrong screen.
With X as a different user, it simply can't happen. No additional config required.
Works for me. Had some trouble previously, but perhaps configuring the default sink in /etc/pulse/default.pa
did the job.
Was just about to attempt forcing the audio device as mentioned above. Really missed Vulkan support while using VLC.
Huzzah!
I just came here trying to get S/PDIF audio with mpv too. Thanks to the comments here I managed to make it work in Ubuntu 18.04 ( Bionic ). I will share it here:
First I listed the PCM devices with: aplay -L
, there I found the name of the sound board and I configured mpv at /etc/mpv/mpv.conf this way:
audio-device=alsa/iec958:CARD=Intel,DEV=0
audio-spdif=ac3,dts
ad-lavc-ac3drc=0
Works like a charm, thank you mpv team, you got my star.
I would like to add that you can force the output of the lavcac3enc
filter to be passthrough to the S/PDIF!
So when you combine it it with --audio-spdif=ac3,dts,eac3
option, you get surround sound through the S/PDIF with all surround sound formats including DTS, DDP, Dolby Digital, Dolby TrueHD.
--audio-spdif=ac3,dts,eac3
--af=lavcac3enc=tospdif=yes
mpv version and platform
[cplayer] mpv 0.27.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
Debian Stretch + amd64 + deb-multimedia-backports
Reproduction steps
No matter what options I use, it seems impossible to get mpv to output an unaltered DTS/AC3 stream to my amp, over SPDIF/coaxial.
mpv will always either:
When sound works, it is always downmixed, and my amp reports 'PCM' as the output format.
Note that mplayer and vlc work fine with my config, and mplayer does successfully output unvarnished DTS-HD/DTS/AC3 to my amp without issues. I've been using this same motherboard + config for 5 years, and this current install of Debian with mplayer for 8+ months with no issue.
My mplayer config for reference:
ac=hwdts,hwac3, ao=alsa:device=hw=0.0 srate=48000
I'm only guessing here, but it seems to me that I'm not using the 'SPDIF' output directly (as per some of the test runs I did in the attached log file..), but is using the default device + SPDIF somehow.
Whatever the case, mplayer doesn't try to downmix, or do anything other than sending raw data for DTS / etc.
Also.. I tried, well, a LOT more permutations than the 5 shown in the log file. I even installed the 'cycledevice' LUA script, so I could more easily find workable devices.
https://gist.github.com/bitingsock/ad58ee5da560ecb922fa4a867ac0ecfd
Happy to create a logfile with any options requested!
Thanks
Log file
http://sprunge.us/AGIe