From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>,
Anssi Hannula <anssi.hannula@iki.fi>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Radeon unconnected HDMI eats samples at 280 kHz
Date: Thu, 18 Sep 2014 09:54:10 +0200 [thread overview]
Message-ID: <541A8FA2.7090406@canonical.com> (raw)
In-Reply-To: <s5hlhph8jt5.wl-tiwai@suse.de>
On 2014-09-18 09:33, Takashi Iwai wrote:
> At Thu, 18 Sep 2014 06:13:01 +0200,
> David Henningsson wrote:
>>
>>
>>
>> On 2014-09-17 23:26, Anssi Hannula wrote:
>>> 17.09.2014, 16:40, David Henningsson kirjoitti:
>>>> Hi,
>>>
>>> Hi,
>>>
>>>> While investigating some interesting debug output from PulseAudio, I
>>>> tried to figure out the cause.
>>>>
>>>> From what I can tell, my Radeon seems to ask for new samples at a very
>>>> high rate, which I estimate to be around 280 kHz. My radeon card has
>>>> DVI, HDMI and VGA connectors, and the only thing connected is my screen
>>>> over DVI.
>>>>
>>>> I'm currently running the 3.13 kernel with updated hda directory from
>>>> Takashi's tree, but I think it's been this way for a long time.
>>>>
>>>> Note that if a screen is connected to the HDMI card, the problem
>>>> disappears and sample rates are normal.
>>>> In short, do you think this is a driver bug, or just something we have
>>>> to live with as some sort of hw anomaly?
>>>> Since nothing is connected, it does not really hurt, except PulseAudio
>>>> gets confused (in a way that could potentially cause problems for
>>>> low-latency output, should something be connected later on).
>>>
>>> Not sure.
>>> IIRC, unlike the other gpus, on radeon the video driver needs to
>>> "manually" set sample rate dividers/etc based on the pixel clock rate,
>>> so I guess this might mean we can't have a proper audio clock without
>>> enabled video...
>>>
>>> Alex, any thoughts/info?
>>>
>>>
>>> If this is the case, it would probably be best if we prevented opening
>>> the device when output is not active (unless this causes some other
>>> issues), but I guess there is currently no easy way for the _audio_
>>> driver to know that...
>>
>> Well, if jack detection (get pin sense) works, there is.
>
> Does it react if we turn off the HDMI output via xrandr, too?
> I'm not sure whether we need reprogram things in that case, though...
xrandr correctly reports that "HDMI-0" is disconnected.
I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
--output HDMI-0 --off" and it made no difference in either xrandr
output, nor in codec/eld output.
What I'm thinking is that it could be that the monitor_present is
indicating the presence of my DVI monitor, as some cards are capable of
outputting HDMI audio on their DVI outputs (through a passive DVI->HDMI
adapter). This is just a guess though.
>> There are two
>> major problems with that though:
>>
>> 1) When I look right here and now, it seems like jack detection returns
>> "plugged in" status, and ELD info reports monitor_present=1,
>> eld_valid=0. So pin sense isn't really working (or maybe it reports that
>> my DVI monitor is plugged in, which isn't helpful here). I'm attaching
>> codec proc info in case it's helpful.
>>
>> 2) It requires major work in PulseAudio to make sure we re-probe the
>> HDMI device when it is plugged in. We should do that anyway, it's just
>> that it is quite some work to do, and noone has done it yet.
>
> Would it make easier if we create/delete HDMI PCM on the fly? Or it's
> rather confusing?
I don't think that would make it any easier for PulseAudio, if anything
it would be more complicated - we would then have to listen to PCM
devices appearing and disappearing and reprobe, instead of listening to
jack detection events and reprobe based on that.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
next prev parent reply other threads:[~2014-09-18 7:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 13:40 Radeon unconnected HDMI eats samples at 280 kHz David Henningsson
2014-09-17 21:26 ` Anssi Hannula
2014-09-18 4:13 ` David Henningsson
2014-09-18 7:33 ` Takashi Iwai
2014-09-18 7:54 ` David Henningsson [this message]
2014-09-18 22:29 ` Deucher, Alexander
2014-09-19 13:38 ` David Henningsson
2014-09-19 14:14 ` Deucher, Alexander
2014-09-19 17:47 ` David Henningsson
2014-09-19 18:19 ` Alexander E. Patrakov
2014-09-19 23:35 ` David Henningsson
2014-09-20 9:37 ` Anssi Hannula
2014-09-20 9:39 ` Alexander E. Patrakov
2014-09-19 23:32 ` Deucher, Alexander
2014-09-20 0:06 ` David Henningsson
2014-09-20 9:31 ` Alexander E. Patrakov
2014-09-22 12:46 ` Deucher, Alexander
2014-09-22 14:39 ` David Henningsson
2014-09-22 14:52 ` Deucher, Alexander
2014-09-23 9:47 ` David Henningsson
2014-09-23 14:07 ` Deucher, Alexander
2014-09-24 9:27 ` David Henningsson
2014-09-24 21:37 ` Deucher, Alexander
2014-09-30 12:24 ` David Henningsson
2014-09-30 12:45 ` Deucher, Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541A8FA2.7090406@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alexander.deucher@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=anssi.hannula@iki.fi \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox