[alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz

[Takashi Iwai]

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...

> 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?


Takashi