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

[Alexander E. Patrakov]

20.09.2014 05:35, David Henningsson wrote:
>
>
> On 2014-09-19 20:19, Alexander E. Patrakov wrote:
>> 19.09.2014 23:47, David Henningsson wrote:
>>> If audio_enabled quickly changes to off and then on when there is a mode
>>> change, it might make sense to *not* wake up the audio driver in this
>>> case, as I assume that the audio capabilities on the HDMI TV will not
>>> change just because the video mode changes.
>>
>> Unfortunately, they will. Some low-resolution video modes just don't
>> have enough pixel clock to transfer the 7.1 audio signal at 192 kHz. See
>> the table on page 105 (shown as 121 in some readers) of
>> http://www.microprocessor.org/HDMISpecification13a.pdf , section "7.3.3
>> Video Dependency".
>
> Ok, I stand corrected. I wonder what the least ugly thing to do would be
> if the user is currently running audio when this happens, e g, if the
> user is running a game with background music, and goes to "video
> settings" and switches mode.
>
> But if such thing would audio glitch anyhow, like it seems maybe we
> should let the audio_enabled signal pass through to the audio side to
> indicate a short disconnection. It's just not going to be that fun
> if/when we implement reprobing the HDMI device on plug in. And also the
> risk of the audio stream switching to somewhere else, like going from
> HDMI to analog.

I think it is appropriate to interrupt the audio stream only if it 
doesn't fit the new mode. Then snd_pcm_writei can return an error code - 
but I don't have a good candidate. Neither -EIO nor -ENODEV nor 
-ESTRPIPE quite fits the bill.

-- 
Alexander E. Patrakov