Date: Sat, 14 Jan 2012 14:27:29 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Michael Schnell <schnell@s-tlk.org> Cc: Yuri Pankov <yuri.pankov@gmail.com>, freebsd-multimedia@freebsd.org, FreeBSD current <freebsd-current@freebsd.org> Subject: Re: [RFT] Major snd_hda rewrite Message-ID: <4F1174B1.9050006@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1201140237130.39714@priv.s-tlk.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <20120112130404.GD1429@procyon.xvoid.org> <alpine.BSF.2.00.1201140237130.39714@priv.s-tlk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.01.2012 04:10, Michael Schnell wrote: > > On Thu, 12 Jan 2012, Yuri Pankov wrote: > >> On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote: >>> On 01/12/12 14:18, Yuri Pankov wrote: >>>> On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote: >>>>> I would like request for testing of my work on further HDA sound >>>>> driver >>>>> improvement. >>>> [...] >>>>> Patch can be found here: >>>>> http://people.freebsd.org/~mav/hda.rewrite.patch >>>>> >>>>> Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE >>>>> and 8-STABLE branches also. >>>> >>>> Patch applied cleanly to r230008 using `svn patch`. >>>> >>>> hdacc0:<NVidia GT220 HDA CODEC> at cad 0 on hdac0 >>>> hdaa0:<NVidia GT220 HDA CODEC Audio Function Group> at nid 1 on hdacc0 >>>> pcm0:<NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)> at nid 5 on hdaa0 >>>> hdacc1:<NVidia GT220 HDA CODEC> at cad 1 on hdac0 >>>> hdaa1:<NVidia GT220 HDA CODEC Audio Function Group> at nid 1 on hdacc1 >>>> pcm1:<NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)> at nid 5 on hdaa1 >>>> hdacc2:<NVidia GT220 HDA CODEC> at cad 2 on hdac0 >>>> hdaa2:<NVidia GT220 HDA CODEC Audio Function Group> at nid 1 on hdacc2 >>>> pcm2:<NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)> at nid 5 on hdaa2 >>>> hdacc3:<NVidia GT220 HDA CODEC> at cad 3 on hdac0 >>>> hdaa3:<NVidia GT220 HDA CODEC Audio Function Group> at nid 1 on hdacc3 >>>> pcm3:<NVidia GT220 HDA CODEC PCM (DisplayPort 8ch)> at nid 5 on hdaa3 >>>> hdacc4:<IDT 92HD75BX HDA CODEC> at cad 0 on hdac1 >>>> hdaa4:<IDT 92HD75BX HDA CODEC Audio Function Group> at nid 1 on hdacc4 >>>> pcm4:<IDT 92HD75BX HDA CODEC PCM (Analog)> at nid 13 and 11 on hdaa4 >>>> pcm5:<IDT 92HD75BX HDA CODEC PCM (Analog)> at nid 15 and 24 on hdaa4 >>>> pcm6:<IDT 92HD75BX HDA CODEC PCM (Front Digital)> at nid 30 on hdaa4 >>>> >>>> pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, >>>> however >>> >>> Thank you. >>> >>>> I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI), >>>> mplayer just pauses at the beggining, trying to cat anything to >>>> /dev/dsp{0-3}.0 gives: >>>> >>>> pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, >>>> channel dead >>>> >>>> It was the same with the old driver and I'm not sure if it's (most >>>> likely) my misconfiguration or a driver problem. >>> >>> It sounds more like a driver problem. HDMI audio is still not very well >>> discovered area, and, according to ALSA reading, NVidia HDMI is also not >>> very standard. Probably I'll finally have to buy something to >>> experiment. What card do you have? >> >> It's a laptop with "nVidia Corporation GT216 [GeForce GT 230M]" (as >> identified by x11/nvidia-driver). >> >> The verbose dmesg is at: >> >> https://www.xvoid.org/stuff/spica.dmesg > > I had the same problem for some time and I was going over the code and > honestly I took some inspiration of how the linux kernel handle this and > added some quirks to the code to get it working. However, after some > time I realize that a sysctl > dev.hdac.<n>.0.polling=1 will do something similar and this also works for > me. I don't think this polling mechanism is a good idea, better would be > some interrupt for state updates but anyway, I was glad that I can here > (digital) music over my receiver with my laptop. I have an NVS 3100M > graphic card and it is connected over a (fragile) Displayport-HDMI adapter. > > I would gladly test this with Alexanders patch, but I only have an > 9.0-RELEASE and I already tried to port the patch back, but this would > take some effort. In addition this is my production system and I already > messed it up enough. ;) I also don't like polling, especially in context of new event timers that are not generating interrupts when not needed. In this patch I haven't even reimplemented polling support while rewriting that part of the code, as for several years since implementing it I haven't seen reports that it was really useful. If it is useful, I'll think of it. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F1174B1.9050006>