| Summary: | TDE apps not directing audio to HDMI when HDMI is enabled | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kristopher <gamrat.kristopher> |
| Component: | arts | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEW --- | ||
| Severity: | minor | CC: | be4youcome, bugwatch, gamrat.kristopher, kb9vqf |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Kristopher
2014-11-10 19:38:18 CST
Do any HDMI options show up in KMix? I was not aware that a desktop environment had to explicitly direct audio to HDMI devices for them to work. Can you post the output of "aplay -l" with your TV connected and on? Thanks! (In reply to Timothy Pearson from comment #1) > Do any HDMI options show up in KMix? No, not even after connecting the HDMI cable and directing video to the TV. This surpised me since, AFAIK, KMix uses ALSA and ALSA detects the HDMI audio output (I instructed mplayer to use HDMI out via ALSA when I was testing). > I was not aware that a desktop environment had to explicitly direct audio to > HDMI devices for them to work. Technically, it does work since I am able to do it from mplayer. However, it does not work from within any GUI application. > Can you post the output of "aplay -l" with your TV connected and on? piki@Piki-PC:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 piki@Piki-PC:~$ aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default:CARD=PCH HDA Intel PCH, ALC269VC Analog Default Audio Device sysdefault:CARD=PCH HDA Intel PCH, ALC269VC Analog Default Audio Device front:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog Front speakers surround40:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output I can successfully *force* KMplayer to use HDMI for audio by adding to Settings -> Configure KMPlayer -> General Option -> MPlayer -> Additional command line arguments the same instruction that I used from the command line with mplayer to make it play audio via HDMI: -ao alsa:device=hdmi This should not be necessary, and will need to be added/removed whenever I connect/disconnect the HDMI cable. Also, this solution is for mplayer, but *not* for xine (I am not familiar with xine, therefor I doubt I can help find a workaround). Overall I think this is probably an arts bug, specifically that sound is not being routed to all available playback devices by default. The only caveat is if you have PulseAudio installed; if you do all bets are off. Can you confirm PulseAudio is not installed on your system? Thanks! (In reply to Timothy Pearson from comment #4) > Overall I think this is probably an arts bug, specifically that sound is not > being routed to all available playback devices by default. The only caveat > is if you have PulseAudio installed; if you do all bets are off. Can you > confirm PulseAudio is not installed on your system? > > Thanks! I can do one better: I can confirm that PulseAudio has literally never been installed on this computer. It started as a "bare bones" Debian install with no sound and went straight to TDE + ALSA with no trace of PulseAudio anywhere. OK, thanks for the info! Whoever works on this bug will need to have more than one sound card installed and properly detected by ALSA; the essence of the bug is arts not routing (duplicating) sound to all sound cards by default. (In reply to Timothy Pearson from comment #6) > OK, thanks for the info! > > Whoever works on this bug will need to have more than one sound card > installed and properly detected by ALSA; the essence of the bug is arts not > routing (duplicating) sound to all sound cards by default. If you look at the output I posted for aplay in comment 2, it seems both the internal speakers and HDMI audio are controlled by the same sound card, since both are listed under "card 0" despite being listed as two separate devices. In the case of Intel integrated chipsets, this actually makes sense since both video and audio controllers are integrated into the same chipset (hence why they're called that). Therefor, it may not be necessary to have two separate sound cards to resolve this (though it wouldn't hurt for testing). As far as I can tell, it relies on the software to tell it whether to send the audio to the internal speakers or the HDMI output, hence why audio continues to play on the internal speakers except when I manually specify to use HDMI (such as with my mplayer workaround for KMplayer). Also, I'd like to point out that there are cases when using all available devices is not desirable: for example, when I connect the HDMI cable and play a movie on the TV, I expect the audio from the movie to play through the TV *only* rather than both the TV and the laptop speakers (though it would still make sense to have stuff on the laptop screen still play the audio through the laptop speakers). Therefor I think there should be a way for the DE to decide which devices to use to play audio, or a way to allow the user to configure it (or, preferrably, both). At this point I start to wonder if hooking in to PulseAudio is the right way to go. PulseAudio is designed to handle these scenarios; ALSA is not. At any rate this is a post-R14 feature request. :-) (In reply to Timothy Pearson from comment #8) > At this point I start to wonder if hooking in to PulseAudio is the right way > to go. PulseAudio is designed to handle these scenarios; ALSA is not. > > At any rate this is a post-R14 feature request. :-) There is a simple reason I've never installed PulseAudio: it has proven itself *very* unstable, at least on Intel integrated chipsets, so using it (for me) is out of the question. |