[PATCH] Support for HDMI Audio on R700 and something a little bit experimental
Hi everybody, attached are two patches. The first one is a simple one bit change, which should get HDMI audio on R700 working. The second is something very experimental: Some people have reported problems with some HDMI receivers. Those receivers needs 1-2 seconds at start of audio playback to adjust to the audio parameters. So you miss the first few seconds off playback. The patch now tries to solve this problem by playing a dummy audio stream only containing silence when there is no other audio to play. I'm abusing the debugging function of the HDMI transmitter, which before has not been used much, so i don't know if this will work on every chipset. @Jaren: Could you try both patches and see if they will fix your problem. @Rafał and every body else on the list: Please try out at least the first patch, to see if it has any negativ effects on other chipsets. Happy testing, Christian.
@Jaren: Could you try both patches and see if they will fix your problem.
Patch 1 worked perfectly. After adding it audio is enabled correctly by the driver on my 4870. Patch 2 is a little hit and miss. The patch seems to be doing what it claims correctly. The receiver will stick with the format of the last played sound until a new sound is played. When playing the same sound over and over the time it takes to start playing sound is dramatically reduced on subsequent plays. However, if I alternate between something that is ac3 and then something in DTS I see the same 1-2 second lag as before. That being said, this is an improvement and it doesn't seem to be hurting anything. More than that, I'm not sure there is much more that can be done other than using something like PulseAudio to capture all your sound and output it all in the same format all the time so that the receiver wouldn't have to constantly switch formats. Thanks a lot for your work Christian! Jaren Peterson -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/6/10 Jaren Peterson
@Jaren: Could you try both patches and see if they will fix your problem.
Patch 1 worked perfectly. After adding it audio is enabled correctly by the driver on my 4870.
Patch 2 is a little hit and miss. The patch seems to be doing what it claims correctly. The receiver will stick with the format of the last played sound until a new sound is played. When playing the same sound over and over the time it takes to start playing sound is dramatically reduced on subsequent plays. However, if I alternate between something that is ac3 and then something in DTS I see the same 1-2 second lag as before.
That being said, this is an improvement and it doesn't seem to be hurting anything. More than that, I'm not sure there is much more that can be done other than using something like PulseAudio to capture all your sound and output it all in the same format all the time so that the receiver wouldn't have to constantly switch formats.
Thanks a lot for your work Christian!
Jaren Peterson
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
I have always considered that second or two delay to be the receiver's fault, and not the driver. Unless you can predict what format will be played and have the silence switch formats before the actual sound is played, I don't think this will help much. But if it doesn't hurt, then why not (or make it an option.) - Patrick -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/6/11 Patrick Oglesby
I have always considered that second or two delay to be the receiver's fault, and not the driver. Unless you can predict what format will be played and have the silence switch formats before the actual sound is played, I don't think this will help much. But if it doesn't hurt, then why not (or make it an option.)
- Patrick
Delays on format changes are to be expected. There's a delay on my receiver when my Playstation 3 changes formats. I would strongly suggest that this fix be an option not a default. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Am Freitag, den 12.06.2009, 08:54 -0400 schrieb kristof:
2009/6/11 Patrick Oglesby
: I have always considered that second or two delay to be the receiver's fault, and not the driver. Unless you can predict what format will be played and have the silence switch formats before the actual sound is played, I don't think this will help much. But if it doesn't hurt, then why not (or make it an option.)
- Patrick
Delays on format changes are to be expected. There's a delay on my receiver when my Playstation 3 changes formats. I would strongly suggest that this fix be an option not a default.
I agree that this should only be an optional feature, and this was rather a prove of concept than a real solution for the problem. But i don't know if this solution will work on every chipset. Did any body beside Jaren tested the patch? I really need more feedback if those patches have any negativ effects on other chipsets. @Jaren: You should see a new message in your Xorg.log witch looks something like: (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: waited 1739 ms for audio stream to start Could you send me a recent Xorg log? Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jun 13, 09 13:56:20 +0200, Christian König wrote:
Am Freitag, den 12.06.2009, 08:54 -0400 schrieb kristof:
Delays on format changes are to be expected. There's a delay on my receiver when my Playstation 3 changes formats. I would strongly suggest that this fix be an option not a default.
I agree that this should only be an optional feature, and this was rather a prove of concept than a real solution for the problem.
So far I see only two reasons why this should be an option:
- We are not sure it works correctly on all chipsets
- Users might like to see a "No Signal" like event if there is no audio
running
This looks like an option that should default to true.
Matthias
--
Matthias Hopf
2009/6/15 Matthias Hopf
On Jun 13, 09 13:56:20 +0200, Christian König wrote:
Am Freitag, den 12.06.2009, 08:54 -0400 schrieb kristof:
Delays on format changes are to be expected. There's a delay on my receiver when my Playstation 3 changes formats. I would strongly suggest that this fix be an option not a default.
I agree that this should only be an optional feature, and this was rather a prove of concept than a real solution for the problem.
So far I see only two reasons why this should be an option:
- We are not sure it works correctly on all chipsets - Users might like to see a "No Signal" like event if there is no audio running
This looks like an option that should default to true
It would be easy enough for every receiver to keep itself ready and waiting to play audio in the last format it saw. It could pretend that it was seeing a bitstream full of "silence" whenever there was no real bitstream. That's not how most digital receivers are designed to function and there's a good reason. Even when a receiver is being fed "silence" it's still doing a lot of work. DSP's are processing. Amplifier stages are operating. Depending on the amplifier class, wattage, number of channels, etc. it can use a significant amount of electricity. When a digital bitstream ends most receivers go into an idle state. It's the audio equivalent of DPMS. They're free to power down DSP's and analog output stages. When they do so it's by design. It's a feature. It's as if some people don't want to wait for their monitor to come back from power saving mode, so they propose that the video driver should output sync signals no matter what. That would disable DPMS for everyone. Spoofing "silence" disables the power saving features of every connected device. It's exactly the same. Some people turn their receiver on when they boot their computer in the morning and turn it off when they shut down at night. Over a day's time, they play an album or two and watch a youtube video. Some (most?) of these people want their receiver to come to life only when needed. They don't want it burning excess electricity all day long when it could be idle most of the time. Spoofing silence has it's use cases but it must remain optional. Even then I would argue that it's a userspace problem. Let the specialty apps or sound daemons handle it when desired. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jun 15, 09 17:14:30 -0400, kristof wrote:
It would be easy enough for every receiver to keep itself ready and waiting to play audio in the last format it saw. It could pretend
To my experience, no one does. They all require a few seconds of audio to synchronize.
that it was seeing a bitstream full of "silence" whenever there was no real bitstream.
A new bitstream can start at any point of time, if the pretended bitstream was in the middle of a packet, synchronization could prove difficult.
it's still doing a lot of work. DSP's are processing. Amplifier stages are operating. Depending on the amplifier class, wattage, number of channels, etc. it can use a significant amount of electricity.
To my experience, A/B amplifiers always run the default current through the main transistors, because otherwise they would cool down, which would change their characteristics. This makes them consume approx 50W on idle. The DSP and analog output stages use negligible power compared to that (< 5W).
It's as if some people don't want to wait for their monitor to come back from power saving mode, so they propose that the video driver should output sync signals no matter what. That would disable DPMS
While theoretically this is comparable, practically monitors do save a
lot of power in soft-off mode. Anyway, I actually don't care about the
default option. Off is fine with me, and if it's even only potentially
saving power, I'm all for it.
CU and thanks
Matthias
P.S. You say when the patches are fine for submission :-)
--
Matthias Hopf
2009/6/11 Christian König
@Rafał and every body else on the list: Please try out at least the first patch, to see if it has any negativ effects on other chipsets.
I'll able to test this on Friday/Saturnday. Can you live with this delay in commiting? :) -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/6/11 Christian König
Hi everybody,
attached are two patches.
The first one is a simple one bit change, which should get HDMI audio on R700 working.
The second is something very experimental: Some people have reported problems with some HDMI receivers. Those receivers needs 1-2 seconds at start of audio playback to adjust to the audio parameters. So you miss the first few seconds off playback. The patch now tries to solve this problem by playing a dummy audio stream only containing silence when there is no other audio to play. I'm abusing the debugging function of the HDMI transmitter, which before has not been used much, so i don't know if this will work on every chipset.
@Jaren: Could you try both patches and see if they will fix your problem.
@Rafał and every body else on the list: Please try out at least the first patch, to see if it has any negativ effects on other chipsets.
Happy testing, Christian.
First patch (R700 support) doesn't cause any regressions on my M82. Second one (experimental) is working somehow weird for me. Normally while not playing audio I get "No signal" on my A/V receiver. While playing something with not hardware codec (not hwac3, not hwdts) I get "Movie" on A/V received display. So I recompiled driver with second patch applied and restarted X. I saw "Movie" on my A/V receiver's display. After starting playback I got auido right after starting, without delay. I used mplayer for this. The weird part is that after pausing playback in mplayer (pause, not quit) it stops playing (obvious) but displays changes to "No signal". And after resuming playback from pause I still get that ~500ms delay. However after quiting mplayer I get "No signal" for ~500ms, and after that time "Movie" again. Aftet getting "Movie" I can start playback again without delay. Uh, that sounds weird, hope you understand this. Just to sum up: I get rid of silence delay only when starting fresh mplayer. After pause&resume in mplayer I've to wait ~500ms anyway. Can you comment on this Christian? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Am Samstag, den 20.06.2009, 02:09 +0200 schrieb Rafał Miłecki:
First patch (R700 support) doesn't cause any regressions on my M82. Good, so i will forward the patch to matthias for inclusion.
Second one (experimental) is working somehow weird for me. Normally while not playing audio I get "No signal" on my A/V receiver. While playing something with not hardware codec (not hwac3, not hwdts) I get "Movie" on A/V received display.
So I recompiled driver with second patch applied and restarted X. I saw "Movie" on my A/V receiver's display. After starting playback I got auido right after starting, without delay. I used mplayer for this.
The weird part is that after pausing playback in mplayer (pause, not quit) it stops playing (obvious) but displays changes to "No signal". And after resuming playback from pause I still get that ~500ms delay.
However after quiting mplayer I get "No signal" for ~500ms, and after that time "Movie" again. Aftet getting "Movie" I can start playback again without delay.
Uh, that sounds weird, hope you understand this. Just to sum up: I get rid of silence delay only when starting fresh mplayer. After pause&resume in mplayer I've to wait ~500ms anyway.
Can you comment on this Christian? Yep, works as expected. The problem here is that i trigger on the audio stream setup, not on the actually audio buffer filled event. This is an mplayer specific behaviour, xine has an option to play silence between suspend/resume (ok i think mplayer has also this option somewhere, but its seems to be turned off by default).
Attached is a new version of the patch, it now checks on the correct bit in the hdmi engine, instead of the stream status bits in the audio engine. I was more successful Beside that i have implemented enabling/disabling this workaround with xorg.conf and xrandr. The default is off, so you need to either put something like Option "AudioWorkaround" "DVI-I_1 DVI-I_2" in your xorg.conf or enable this with xrandr. Bye, Christian.
W dniu 21 czerwca 2009 17:59 użytkownik Christian König
Attached is a new version of the patch, it now checks on the correct bit in the hdmi engine, instead of the stream status bits in the audio engine. I was more successful
First of all, whitespace warning appears: zajec@linux-aodr:~/xf86-video-radeonhd> git am ../0002-Audio-dummy-stream-workaround.patch Applying: Audio dummy stream workaround /home/zajec/xf86-video-radeonhd/.git/rebase-apply/patch:349: trailing whitespace. __func__, IsAudioBufferFilled(hdmi) ? "playing" : "stoped", /home/zajec/xf86-video-radeonhd/.git/rebase-apply/patch:430: trailing whitespace. } else { warning: 2 lines add whitespace errors.
Beside that i have implemented enabling/disabling this workaround with xorg.conf and xrandr. The default is off, so you need to either put something like Option "AudioWorkaround" "DVI-I_1 DVI-I_2" in your xorg.conf or enable this with xrandr.
OK, so I tried this version with: Option "HDMI" "DVI-D_1" Option "AudioWorkaround" "DVI-D_1" but it doesn't seem to work for me. I don't get any /not recognised option/ in log, but my A/V receiver displays "No Signal" after starting X and after stopping video. Next problem is that after playing more with first version of your patch I noticed lockups on starting mplayer with -ss option. For example: mplayer -vo xv -ao alsa:device=hw=1.3 -ss 6401 file.mkv lockups with "Starting playback" message from MPlayer. ACPI power down doesn't work, ALT+CTRL+BACKSPACE doesn't work, SysRq fortunately works. Can you reproduce this with first version of your patch? Does it still happen for you with second version? My file.mkv is: [mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0 [mkv] Track ID 2: audio (A_DTS), -aid 0, -alang eng -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
W dniu 22 czerwca 2009 01:10 użytkownik Rafał Miłecki
Beside that i have implemented enabling/disabling this workaround with xorg.conf and xrandr. The default is off, so you need to either put something like Option "AudioWorkaround" "DVI-I_1 DVI-I_2" in your xorg.conf or enable this with xrandr.
OK, so I tried this version with: Option "HDMI" "DVI-D_1" Option "AudioWorkaround" "DVI-D_1" but it doesn't seem to work for me. I don't get any /not recognised option/ in log, but my A/V receiver displays "No Signal" after starting X and after stopping video.
Plus I didn't get any new xrandr prop with second version of patch. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Am Montag, den 22.06.2009, 15:18 +0200 schrieb Rafał Miłecki:
OK, so I tried this version with: Option "HDMI" "DVI-D_1" Option "AudioWorkaround" "DVI-D_1" but it doesn't seem to work for me. I don't get any /not recognised option/ in log, but my A/V receiver displays "No Signal" after starting X and after stopping video.
Plus I didn't get any new xrandr prop with second version of patch. Attached is the third version of this patch, fixed is a bug which disables the option on chipsets with DIG output interface (which includes your M86).
IMHO this should have a more descriptive name - like "AudioStreamSilence" or "AudioActiveSilence" or "AudioContinueIfInactive" or... I changed the name of the option to AudioStreamSilence.
Next problem is that after playing more with first version of your patch I noticed lockups on starting mplayer with -ss option. For example: mplayer -vo xv -ao alsa:device=hw=1.3 -ss 6401 file.mkv Mhm, in the first version of the patch i waited in a busy loop for the audio buffer to be filled, my best guess would be that this busy loop triggers a bug in the xv code, which in the end leaves the system unusable. Since i removed the busy loop this problem should disappear.
Bye, Christian.
W dniu 23 czerwca 2009 20:54 użytkownik Christian König
Am Montag, den 22.06.2009, 15:18 +0200 schrieb Rafał Miłecki:
OK, so I tried this version with: Option "HDMI" "DVI-D_1" Option "AudioWorkaround" "DVI-D_1" but it doesn't seem to work for me. I don't get any /not recognised option/ in log, but my A/V receiver displays "No Signal" after starting X and after stopping video.
Plus I didn't get any new xrandr prop with second version of patch. Attached is the third version of this patch, fixed is a bug which disables the option on chipsets with DIG output interface (which includes your M86).
IMHO this should have a more descriptive name - like "AudioStreamSilence" or "AudioActiveSilence" or "AudioContinueIfInactive" or... I changed the name of the option to AudioStreamSilence.
Next problem is that after playing more with first version of your patch I noticed lockups on starting mplayer with -ss option. For example: mplayer -vo xv -ao alsa:device=hw=1.3 -ss 6401 file.mkv Mhm, in the first version of the patch i waited in a busy loop for the audio buffer to be filled, my best guess would be that this busy loop triggers a bug in the xv code, which in the end leaves the system unusable. Since i removed the busy loop this problem should disappear.
Ups, I've left my house few hours ago :-/ Will be back on next Monday, until then I can't test your patch. Consider how /dangerous/ is your patch and decide with Matthias if you prefer to wait for my tests. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jun 23, 09 21:10:58 +0200, Rafał Miłecki wrote:
IMHO this should have a more descriptive name - like "AudioStreamSilence" or "AudioActiveSilence" or "AudioContinueIfInactive" or... I changed the name of the option to AudioStreamSilence.
Thanks :)
Next problem is that after playing more with first version of your patch I noticed lockups on starting mplayer with -ss option. For example: mplayer -vo xv -ao alsa:device=hw=1.3 -ss 6401 file.mkv Mhm, in the first version of the patch i waited in a busy loop for the audio buffer to be filled, my best guess would be that this busy loop triggers a bug in the xv code, which in the end leaves the system unusable. Since i removed the busy loop this problem should disappear.
Ups, I've left my house few hours ago :-/ Will be back on next Monday, until then I can't test your patch.
Consider how /dangerous/ is your patch and decide with Matthias if you prefer to wait for my tests.
I would suggest that there is no need to hurry.
Monday is perfectly fine.
Thanks for testing, Rafal!
Matthias
--
Matthias Hopf
W dniu 23 czerwca 2009 20:54 użytkownik Christian König
Attached is the third version of this patch, fixed is a bug which disables the option on chipsets with DIG output interface (which includes your M86).
Generally it works, but it's still not perfect. After I stop or pause playback it takes about 1-2secs for driver to start transmitting silent signal. So if I pause and resume playback right after, I still get this 1-2secs of dropped audio. The same happens if I stop mplayer and start it right after. Is this something you can also fix/workaround? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
W dniu 29 czerwca 2009 19:57 użytkownik Rafał Miłecki
W dniu 23 czerwca 2009 20:54 użytkownik Christian König
napisał: Attached is the third version of this patch, fixed is a bug which disables the option on chipsets with DIG output interface (which includes your M86).
Generally it works, but it's still not perfect. After I stop or pause playback it takes about 1-2secs for driver to start transmitting silent signal. So if I pause and resume playback right after, I still get this 1-2secs of dropped audio. The same happens if I stop mplayer and start it right after.
Is this something you can also fix/workaround?
Ping :) -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Am Dienstag, den 07.07.2009, 08:37 +0200 schrieb Rafał Miłecki:
Is this something you can also fix/workaround?
Ping :) I tried desperately to fix this for the past weekend, but with no success. The problem is that the first sign of a stoped audio stream is a status bit with i think indicates a buffer underrun, and at this point its to late to start up the silence audio stream.
I also tried to check the byte counter for any change in how much bytes are transfered in the last couple of ms, but even this is to late. I'm running out of ideas, and fear as long as nobody invented precognition, this will stay an unfixed problem. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jul 07, 09 19:33:48 +0200, Christian König wrote:
Am Dienstag, den 07.07.2009, 08:37 +0200 schrieb Rafał Miłecki:
Is this something you can also fix/workaround? Ping :) I tried desperately to fix this for the past weekend, but with no success. The problem is that the first sign of a stoped audio stream is a status bit with i think indicates a buffer underrun, and at this point its to late to start up the silence audio stream.
I also tried to check the byte counter for any change in how much bytes are transfered in the last couple of ms, but even this is to late.
I'm running out of ideas, and fear as long as nobody invented precognition, this will stay an unfixed problem.
So what shall we do? Apply the patch as is, or keep the original setting
(w/o introducing the silence stream)?
Matthias
--
Matthias Hopf
On Jun 21, 09 17:59:29 +0200, Christian König wrote:
Beside that i have implemented enabling/disabling this workaround with xorg.conf and xrandr. The default is off, so you need to either put something like Option "AudioWorkaround" "DVI-I_1 DVI-I_2" in your xorg.conf or enable this with xrandr.
IMHO this should have a more descriptive name - like
"AudioStreamSilence" or "AudioActiveSilence" or
"AudioContinueIfInactive" or...
CU
Matthias
--
Matthias Hopf
participants (6)
-
Christian König
-
Jaren Peterson
-
kristof
-
Matthias Hopf
-
Patrick Oglesby
-
Rafał Miłecki