- Alsa-devel - mailman.alsa-project.org

[alsa-devel] Aloop master volume and oss
by Gustavo da Silva Serra 05 May '08

05 May '08

Hi! I am using aloop and everything works fine, but when I try to increase or decrease master volume in alsamixer, oss applications continue to play at maximum volume. When I am using a sound card, master volume affects oss applications. Is this an aloop configuration issue? Thanks in advance.

1 0

Re: [alsa-devel] [pulseaudio-discuss] alsa pulse bugs
by tom＠dbservice.com 05 May '08

05 May '08

Quoting Colin Guthrie <gmane(a)colin.guthr.ie>: > Actually just having a very quick glance at the Alsa API docs, it > doesn't mention that this value should be 0 if there are no samples to play: > > http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4… > > Closest it says is: "It's positive and less than buffer size in normal > situation". > > So perhaps this is an invalid assumption at the wine side? However this part: Delay is distance between current application frame position and sound frame position. suggests that it indeed can be zero. Or why would a soundcard have a gap between the read and write positions if it has played everything? If Wine uses a wrong assumption, then please clarify the function description. > Is there perhaps a more appropriate API call they can use to do whatever > test they are doing? What Wine needs to know, is whether a particular sample has already been played or not. It does 'bytes_written - delay_in_bytes' to find out how much of the written data the soundcard has already played. If there is a better test for it, please explain. tom

1 0

Re: [alsa-devel] [pulseaudio-discuss] alsa pulse bugs
by tom＠dbservice.com 05 May '08

05 May '08

Quoting Colin Guthrie <gmane(a)colin.guthr.ie>: Attached patches to #3943 and #3944. Please read the comments there. > tom(a)dbservice.com wrote: >>> Re the snd_pcm_delay() including network latency (#3945), this clearly >>> makes sense for network streams. Does you proposed fix include this >>> delay (albeit with the improvement that it also will drop to 0 if there >>> are no samples queued)? >> >> snd_pcm_delay() should not include any network latency. The API is >> defined as 'read pointer - write pointer', and applications expect >> that. Or at least they expect that when all samples are played that >> the delay drops to zero. > > With the caveat of very limited technical knowledge, I can agree on the > latter point (drop to 0 when all samples are played), but if it was > implemented sans net-delay in pulse would this not cause e.g. a-v sync > issues when playing via alsa to a networked PA server? If so then this > fix would introduce another bug. Your arguments seem reasonable. Let's see what others have to say to it. It would be interesting to see how much delay such change introduces. I can't test PA over network at home, but if someone wants, the patch is attached to the bug entry in the alsa bugtracker. >>> Also re #3942, I believe (but not sure) that the max buffer in the >>> glitch free branch has been increased significantly (as it now needs to >>> keep some degree of past sound as well as future buffer to allow the >>> rewinds to work properly (this is no doubt an inaccurate description of >>> why it's needed.... :p)) I'm not sure how this would affect this >>> solution, but Lennart will be able to advise better. >> >> I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that >> applications can make use of it. If the max buffer length has been >> increased, then the alsa pulse plugin should be able to propagate that >> to applications using the alsa API. > > Well I'm not sure of the internals of the glitch-free stuff, but I doubt > it's a buffer that can be used in quite the same way as that. Lennart > will be able to advise if I've got the wrong end of the stick in my > comments :) tom

1 0

Re: [alsa-devel] [pulseaudio-discuss] alsa pulse bugs
by tom＠dbservice.com 05 May '08

05 May '08

Quoting Colin Guthrie <gmane(a)colin.guthr.ie>: > tom(a)dbservice.com wrote: >> I reported three bugs to the alsa bugtracker: >> >> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942 >> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943 >> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944 >> >> It's three bugs after all. Once these are fixed I expect Wine to work. >> *fingers crossed* > > Ace Tom :) > > I've cross posted this to the alsa devel list. Hopefully Takashi (who's > committed some pulse-related stuff recently) will have some insight here. > > Re the snd_pcm_delay() including network latency (#3945), this clearly > makes sense for network streams. Does you proposed fix include this > delay (albeit with the improvement that it also will drop to 0 if there > are no samples queued)? snd_pcm_delay() should not include any network latency. The API is defined as 'read pointer - write pointer', and applications expect that. Or at least they expect that when all samples are played that the delay drops to zero. And no, my current patch does not include network latency at all. It simply does what alsa does, 'read pointer - write pointer'. > Also re #3942, I believe (but not sure) that the max buffer in the > glitch free branch has been increased significantly (as it now needs to > keep some degree of past sound as well as future buffer to allow the > rewinds to work properly (this is no doubt an inaccurate description of > why it's needed.... :p)) I'm not sure how this would affect this > solution, but Lennart will be able to advise better. I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that applications can make use of it. If the max buffer length has been increased, then the alsa pulse plugin should be able to propagate that to applications using the alsa API. tom

1 0

Re: [alsa-devel] [PATCH 2.6.25.1] S3C2410 i2s programming error
by Liam Girdwood 04 May '08

04 May '08

On Sun, 2008-05-04 at 15:00 +0200, ing. Davide Rizzo wrote: > S3C2410 i2s driver currently manages only i2s protocol (and not left > justified one) and slave mode. > With this small patch, other modes are possible. > Davide > > > plain text document attachment (s3c24xx-i2s.patch) > This patch to correctly manage codecs in slave mode and left-justified format > > Signed-off-by: Davide Rizzo <davide(a)elpa.it> > ================================================================================ > --- linux-2.6.25.1/sound/soc/s3c24xx/s3c24xx-i2s.c 2008-04-17 04:49:44.000000000 +0200 > +++ linux-2.6.25.1.elpa/sound/soc/s3c24xx/s3c24xx-i2s.c 2008-05-04 09:23:34.000000000 +0200 > @@ -224,6 +224,7 @@ static int s3c24xx_i2s_set_fmt(struct sn > iismod |= S3C2410_IISMOD_SLAVE; > break; > case SND_SOC_DAIFMT_CBS_CFS: > + iismod &= ~S3C2410_IISMOD_SLAVE; > break; > default: > return -EINVAL; > @@ -234,6 +235,7 @@ static int s3c24xx_i2s_set_fmt(struct sn > iismod |= S3C2410_IISMOD_MSB; > break; > case SND_SOC_DAIFMT_I2S: > + iismod &= ~S3C2410_IISMOD_MSB; > break; > default: > return -EINVAL; > ------------------------------------------------------------------- Acked-by: Liam Girdwood <lg(a)opensource.wolfsonmicro.com>

1 0

Re: [alsa-devel] [PATCH 2.6.25.1] S3C2410 pcm audio broken
by Liam Girdwood 04 May '08

04 May '08

On Sun, 2008-05-04 at 14:57 +0200, ing. Davide Rizzo wrote: > S3C2410 pcm doesn't work. > s3c2410_dma_request() now returns the channel number and not 0 if OK. > Davide > plain text document attachment (s3c24xx-pcm.patch) > This patch to update to a s3c2410_dma_request return value change > > Signed-off-by: Davide Rizzo <davide(a)elpa.it> > ================================================================================ > --- linux-2.6.25.1/sound/soc/s3c24xx/s3c24xx-pcm.c 2008-04-17 04:49:44.000000000 +0200 > +++ linux-2.6.25.1.elpa/sound/soc/s3c24xx/s3c24xx-pcm.c 2008-05-04 09:27:46.000000000 +0200 > @@ -171,7 +171,7 @@ static int s3c24xx_pcm_hw_params(struct > ret = s3c2410_dma_request(prtd->params->channel, > prtd->params->client, NULL); > > - if (ret) { > + if (ret < 0) { > DBG(KERN_ERR "failed to get dma channel\n"); > return ret; > } > ------------------------------------------------------------------- Acked-by: Liam Girdwood <lg(a)opensource.wolfsonmicro.com>

1 0

[alsa-devel] Spdif clock switching?
by Bart de Boer 04 May '08

04 May '08

Hi all, I have some weird behavior with my Realtek ALC650F chip and it was suggested at Alsa-user (by Dominique Dumont) to post my case here. It may concern a bug in the via82xx driver. I've used the same subject at Alsa-user in case someone wants to check the discussion over there. I'm trying to get all audio (44.1 kHz music and 48 kHz video) through my SPDIF link. I have succeeded at this. I am able to get bitperfect 44.1 kHz digital audio with MythMusic and I'm able to get bitperfect 48 kHz digital audio with mplayer. However, after playing 48 kHz material the system doesn't switch back to 44.1 kHz mode! It seems to be stuck at 48 kHz. The only way to trigger the system back into 44.1 kHz is to play some 44.1 kHz sample through the iec958 device (which will play the 44.1 kHz sample too fast at 48 kHz). After this I'm able to get 44.1 kHz digital audio through the analog device again. :| These are the settings I'm using: alsamixer ========= Unmute "IEC958" Set "IEC958 Playback AC97-SPSA" to 0 (0%) MythTV (General) ================ Audio output device: ALSA:default SPDIF passthrough device: ALSA:iec958:{AES0 0x02} [x] enable AC3 to SPDIF passthrough [x] enable DTS to SPDIF passthrough MythTV (Music) ============== Audio output device: default Ubuntu 8.04 - Sound Preferences =============================== Everything set to: Intel ICH5 - IEC958 .asoundrc ========= pcm.!default { type plug slave.pcm "analog-hw" # slave.pcm "digital-hw" # slave.pcm "dmix-digital" } ctl.!default { type hw card 0 } pcm.analog { type plug slave.pcm "analog-hw" } ctl.analog { type hw card 0 } pcm.analog-hw { type hw card 0 ## The default value for device is 0, so no need to specify ## - Uncomment one of the below or create a new "device N" line as appropriate ## for your sound card or # device 1 # device 4 } ctl.analog-hw { type hw card 0 } pcm.digital-hw { type hw card 0 ## - Comment out "device 1" above and uncomment one of the below or create a ## new "device N" line as appropriate for your sound card or # device 1 # device 2 device 4 } ctl.digital-hw { type hw card 0 } pcm.dmix-digital { type dmix ipc_key 1235 slave { pcm "digital-hw" period_time 0 period_size 1024 buffer_size 4096 rate 48000 } } ctl.dmix-digital { type hw card 0 } mplayer config ============== monitoraspect=16:9 fs=yes vo=xv # ao=alsa ao=alsa:device=iec958 # ao=alsa:device=hw=0.4 # ao=alsa:device=spdif afm=hwac3 $ cat /proc/asound/card0/codec97#0/ac97#0-0 =========================================== 0-0/0: Realtek ALC650F PCI Subsys Vendor: 0x1509 PCI Subsys Device: 0x9202 Capabilities : DAC resolution : 20-bit ADC resolution : 18-bit 3D enhancement : Realtek 3D Stereo Enhancement Current setup Mic gain : +0dB [+0dB] POP path : pre 3D Sim. stereo : off 3D enhancement : off Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Double rate slots: 10/11 Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA Extended status : SPCV LDAC SDAC CDAC SPDIF=3/4 SPDIF VRA PCM front DAC : 44100Hz PCM Surr DAC : 44100Hz PCM LFE DAC : 44100Hz PCM ADC : 44100Hz SPDIF Control : Consumer PCM Copyright Category=0x2 Generation=1 Rate=44.1kHz SPDIF In Status : Not Locked I hope someone can shed some light. :) Bart

1 0

Re: [alsa-devel] [Alsa-user] Jetway j7f2 via82xx volume problem: sound suddenly stops when increasing volume: "SOLVED" (well ... sort of)
by Zoilo Gomez 03 May '08

03 May '08

(Sorry for cross-posting from alsa-user; however, on 2nd thought I think this really belongs in alsa-devel): === I think I have found what is causing this problem: in ac97_patch.c / int patch_vt1617a(...) there is a line of code: >>> snd_ac97_write_cache(a97, 0x5c, 0x20); According to a comment, this code is supposed to "bring the analog power consumption to normal, like WinXP driver for EPIA SP". If I comment out this line, the problem appears to be solved ... I can now put all volume controls to maximum values and the sound will keep playing. This is consistent with the apparent introduction of this bug in kernel 2.6.19 (includes alsa-driver version 1.0.12rc1): no such problem occurred until 2.6.18, but all kernels since 2.6.19 do suffer from this problem. The line of code above first shows up in linux-2.6.19. Unfortunately, since I do not have a datasheet for the VT1617A chip set, I cannot verify the exact semantics, or suggest an improvement. Can anyone with a datasheet please suggest a proper patch to this line of code? TIA, Z. ====== Zoilo Gomez wrote: > In the mean time I have found that kernels 2.6.15 and 2.6.16 do not > suffer from this problem, whereas 2.6.22 till 2.6.25 do. > > Testing for kernels 2.6.17 till 2.6.21 is somewhat complicated in my > setup, because there are other problems (NFS-related) which I need to > sort out. > > So it looks like there is a bug somehow. > > Providing the dxs_support parameter does not make any difference, no > matter what value I set it to. > > Z. > > > Zoilo Gomez wrote: >> I have several J7F2 boards from Jetway, containing a 8237 via sound >> device on the south bridge. >> >> Using the alsa-driver, when I increase the volume then at some point >> all over sudden the sound stops. On some boards this happens at 75%, >> on others already at 60%, or 90%. Bringing the volume down again does >> not bring the audio back ... >> >> I am using the alsa-drivers with MPlayer. >> >> Although to me this smells like a hardware problem, I understand from >> googling around that this can be fixed with software, but I cannot >> find the correct solution anywhere. I have tested with gentoo kernels >> 2.6.22 and 2.6.24. >> >> AFAIK there are only 2 ways to get the sound back once it has stopped: >> >> 1) reset the mobo >> 2) rmmod snd-via82xx, followed by modprobe snd-via82xx >> >> The strange thing is that in option 2), the problem seems to be gone >> once the driver has been reloaded; from that moment on it is working >> fine ....! >> >> There is a driver from Via Arena (viaudiocombo) that seems to work >> fine, but it is OSS i.o. ALSA, and also a development by Via Arena >> i.o. the Linux community. Besides, I need synchronization features >> from the audio driver, and I do not think that OSS support this (not >> 100% sure). >> >> >> Can anyone help me and shed light on this? >> >> >> TIA! >> >> Zoilo. >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save >> $100. Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java… >> >> _______________________________________________ >> Alsa-user mailing list >> Alsa-user(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/alsa-user >> >> >> > > >

2 9

[alsa-devel] error using aplay
by Will Wagner 02 May '08

02 May '08

I have cross compiled alsa-lib & alsa-utils for my arm platform. All appears to be working as speaker_test works fine (and have had the kernel sound driver working previously). However when I try to play a wav file with aplay it fails. This is because in set_params(), after initialising the hardware (which happens with no errors), it then tries to read back the period_size with the call: snd_pcm_hw_params_get_period_size(params, &chunk_size, 0); Which for the file I am playing should return 2048 but instead returns zero. After that it reallocs the buffer to zero size and exits. To try to work out what's going wrong I have been debugging this and inspecting params get the following: (gdb) p *params $21 = {flags = 0, masks = {{bits = {8, 0, 0, 0, 0, 0, 0, 0}}, {bits = {4, 0, 0, 0, 0, 0, 0, 0}}, {bits = {1, 0, 0, 0, 0, 0, 0, 0}}}, mres = {{ bits = {0, 0, 0, 0, 0, 0, 0, 0}}, {bits = {0, 0, 0, 0, 0, 0, 0, 0}}, { bits = {0, 0, 0, 0, 0, 0, 0, 0}}, {bits = {0, 0, 0, 0, 0, 0, 0, 0}}, { bits = {0, 0, 0, 0, 0, 0, 0, 0}}}, intervals = {{min = 16, max = 16, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 32, max = 32, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 2, max = 2, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 22050, max = 22050, openmin = 0, openmax = 0, integer = 1, empty = 0}, { min = 92879, max = 92880, openmin = 1, openmax = 1, integer = 0, empty = 0}, {min = 2048, max = 2048, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 8192, max = 8192, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 5, max = 5, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 464399, max = 464400, openmin = 1, openmax = 1, integer = 0, empty = 0}, {min = 10240, max = 10240, openmin = 0, openmax = 0, integer = 1, empty = 0}, { min = 40960, max = 40960, openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 10000, max = 10000, openmin = 0, openmax = 0, integer = 1, empty = 0}}, ires = {{min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin = 0, openmax = 0, integer = 0, empty = 0}}, rmask = 0, cmask = 1048327, info = 65795, msbits = 16, rate_num = 22050, rate_den = 1, fifo_size = 0, reserved = '\0' <repeats 63 times>} My reading of this is that period_size is correct at 2048, however openmin is 0 (dont' know what openmin is all about). So inspecting the code I thought this should all work. However it appears that there is some magic going on with functions being redirected as a backtrace shows: (gdb) bt #0 __snd_pcm_hw_params_get_period_size (params=0xbef44700, val=0xbef44674, dir=0x2166c) at pcm.c:4263 #1 0x4006f1c8 in __old_snd_pcm_hw_params_get_period_size (params=0xbef44700, dir=0x2166c) at pcm.c:6822 #2 0x0000eda0 in set_params () at aplay.c:983 #3 0x00014004 in playback_go (fd=4, loaded=0, count=171008, rtype=2, name=0xbef44de7 "/sdcard/sounds/tada.wav") at aplay.c:1950 #4 0x000147b8 in playback (name=0xbef44de7 "/sdcard/sounds/tada.wav") at aplay.c:2042 #5 0x0000c8c4 in main (argc=3, argv=0xbef44ce4) at aplay.c:615 It seems the call is somehow being redirected through __old_snd_pcm_hw_params_get_period_size and the implementation of this means that I end up returning openmin instead of min for period_size. Can someone explain what is going on here? Why am I being redirected through this old function? Is it correct that I should be reading openmin here? Any help much appreciated. Will. -- ------------------------------------------------------------------------ Will Wagner will_wagner(a)carallon.com Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ------------------------------------------------------------------------

2 1

[alsa-devel] Another unknown bt878
by John R. 02 May '08

02 May '08

Sound doesn't work on my bt878 based card. Let me know what other information is needed... kernel 2.6.24.2: Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa00:0x1460 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:00.1[A] -> GSI 18 (level, low) -> IRQ 18 Apr 14 20:28:38 server kernel: bt87x0: Using board 0, analog, digital (rate 32000 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa01:0x1461 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:01.1[A] -> GSI 19 (level, low) -> IRQ 19 Apr 14 20:28:38 server kernel: bt87x1: Using board 0, analog, digital (rate 32000 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa02:0x1462 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:02.1[A] -> GSI 16 (level, low) -> IRQ 16 Apr 14 20:28:38 server kernel: bt87x2: Using board 0, analog, digital (rate 3200 0 Hz) Apr 14 20:28:38 server kernel: unknown card 0x878-0xaa03:0x1463 Apr 14 20:28:38 server kernel: please mail id, board name, and, if it works, the correct digital_rate option to <alsa-devel(a)alsa-project.org> Apr 14 20:28:38 server kernel: ACPI: PCI Interrupt 0000:05:03.1[A] -> GSI 17 (level, low) -> IRQ 17 Apr 14 20:28:38 server kernel: bt87x3: Using board 0, analog, digital (rate 32000 Hz) lspci: 05:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:01.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:01.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:02.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:02.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 05:03.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 05:03.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) at boot: bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 bttv0: Bt878 (rev 17) at 0000:05:00.0, irq: 18, latency: 64, mmio: 0xdfcfe000 bttv0: detected: Provideo PV150A-1 [card=98], PCI subsystem ID is aa00:1460 bttv0: using: ProVideo PV150 [card=98,autodetected] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv0: tuner absent bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (1). ACPI: PCI Interrupt 0000:05:01.0[A] -> GSI 19 (level, low) -> IRQ 19 bttv1: Bt878 (rev 17) at 0000:05:01.0, irq: 19, latency: 64, mmio: 0xdfcfc000 bttv1: detected: Provideo PV150A-2 [card=98], PCI subsystem ID is aa01:1461 bttv1: using: ProVideo PV150 [card=98,autodetected] bttv1: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv1: tuner absent bttv1: registered device video1 bttv1: registered device vbi1 bttv1: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (2). ACPI: PCI Interrupt 0000:05:02.0[A] -> GSI 16 (level, low) -> IRQ 16 bttv2: Bt878 (rev 17) at 0000:05:02.0, irq: 16, latency: 64, mmio: 0xdfcfa000 bttv2: detected: Provideo PV150A-3 [card=98], PCI subsystem ID is aa02:1462 bttv2: using: ProVideo PV150 [card=98,autodetected] bttv2: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv2: tuner absent bttv2: registered device video2 bttv2: registered device vbi2 bttv2: PLL: 28636363 => 35468950 .. ok bttv: Bt8xx card found (3). ACPI: PCI Interrupt 0000:05:03.0[A] -> GSI 17 (level, low) -> IRQ 17 bttv3: Bt878 (rev 17) at 0000:05:03.0, irq: 17, latency: 64, mmio: 0xdfcf8000 bttv3: detected: Provideo PV150A-4 [card=98], PCI subsystem ID is aa03:1463 bttv3: using: ProVideo PV150 [card=98,autodetected] bttv3: gpio: en=00000000, out=00000000 in=00ffffff [init] bttv3: tuner absent bttv3: registered device video3 bttv3: registered device vbi3 bttv3: PLL: 28636363 => 35468950 .. ok

2 2