Re: [alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
Hi David,
On Tue, Nov 10, 2009 at 06:35:05PM +0800, David Härdeman wrote:
On Thu, Nov 05, 2009 at 05:06:22PM +0800, David Härdeman wrote:
On Thu, November 5, 2009 08:47, Wu Fengguang wrote:
Attached is my updated patchset, which includes the sticky stream/infoframe features.
Thanks, I'll take a look at it as soon as possible.
I've read through the latest set of patches you sent me and also compiled a kernel using them. The patches look good and work great (save for the fact that I still have a 0.2s silence, but it's still a big improvement). I'd be happy to see them go upstream :)
Thank you :)
You mean 0.2s silence, not 0.2s lost of audio samples? I'd say you have smart ears :) Did you compared the playback over HDMI vs over legacy audio and feel the silence at start of HDMI stream?
On a related note, I still think the only way to get a really flawless playback on my picky receiver is to implement some kind of "silentstream" as mentioned earlier (since then I've also tried messing with VCFG and V, but it seems to upset my receiver even more than complete silence since it will take even longer to provide sounds once audio starts flowing again).
Some other drivers seem to support it (though implemented via hardware specific means), one example: http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=422ac...
Do you think you could ask your colleagues at Intel to explain how they've implemented silentstream in the windows driver?
Hmm, I'm not sure if it would be possible. I'll check it.
Thanks, Fengguang
Hi,
To all the folks reading this on alsa list, sorry for the offtopic, i hope pressing 'd' one extra time is "ok" for you.
On Wed, Nov 11, 2009 at 03:05:40PM +0800, Wu Fengguang wrote:
Do you think you could ask your colleagues at Intel to explain how they've implemented silentstream in the windows driver?
Hmm, I'm not sure if it would be possible. I'll check it.
I'm sorry for a silly comment but that sounds so wrong in so many ways that i just can't resist.
I'm sure you're not lying and that means that Intel internally works in a really freaking ridiculously strange ineffective way that even bears some signs of insanity, right?
How on Earth can it be not possible to obtain details about driver implementation? It can't be unmaintained, therefore there're developers who understand the codebase and for whom it shouldn't be hard to give a precise answer. Moreover it's unlikely it's hard to determine the original author of the feature (using git blame like facilities) and ask him about it. At least that's how things like that generally work. I can't even imagine how much a process must be screwed up to not allow that.
Another example about Intel is their WiMax drivers. They've written some (i assume decent since they were accepted mainline) drivers for their high-quality wimax chipsets. But to actually use them they require user-space supplicant (a bit like wpa_supplicant but different enough). And somehow it happened that the supplicant is binary x86-only (not even amd64!). At the same time they're working on a binary supplicant for arm (n810 wimax edition) and at the same time they're working on a "open source" supplicant.
One less obvious manifistation of "suboptimal" code is the intel's X.org drivers. For quite some time they relied on video bios in one way or another instead of doing proper register-level modesetting, of course with all ill effects attached. And when i needed to use i915resolution to get native mode for my laptop panel i felt like i got in some kind of absurdist tale, and not in a nice way.
I'm sure there's some important reason behind all that but to an outsider that looks just really frustratingly fucked up.
Wu, thank you personally for all your work and involvment and efforts! And if you by any chance can forward my mail to some sane PR guys, please do, it would be nice to understand that things like that are _bad_ PR.
Good luck and happy hacking, Wu :)
participants (2)
-
Paul Fertser -
Wu Fengguang