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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.