[pvrusb2] Terratec Grabster AV400

Mike Isely isely at isely.net
Sun May 17 17:19:21 CDT 2009


On Sat, 16 May 2009, Sven Barth wrote:

> Hello Mike!
> 
> > >/ Hi Mike!
> > />/ />/ I got it working!! But I didn't use the cs5345... I applied the
> > "patch" that
> > />/ Tobias Seiler reported in September:
> > />/ http://www.isely.net/pipermail/pvrusb2/2008-September/001892.html8
> > />/ />/ I simply changed the default value of the cx25840 (in
> > cx25840-core.c) from
> > />/ AUDIO8 to SERIAL_AUDIO and after I compiled the module I get a normal
> > sound.
> > /
> > Changing that default unfortunately is not appropriate because other drivers
> > use that module.
> > 
> > If anything, the "default" should not matter since we should be overriding
> > it as part of the device set up.  So I'm really puzzled here.
> > 
> > There's some debug code that I believe you can turn on in cx25840.ko.  Try
> > explicitly loading the module with "debug=1" as an option.
> >   
> I know that it's not a solution, but it shows the source of the problem (I
> think).
> 
> I tested the cx25840 module with the debug option (I tested both, the modified
> and the original). The resulting debug output is attached. But it is as
> described: the original module does not set the audio to 0 (SERIAL_AUDIO), but
> keeps its default value.

We need to turn on enough debugging to figure out exactly what that 
module is doing to set up the audio routing.


> 
> > >/ />/ Did you use SERIAL_AUDIO anywhere else? Does it work there? Might
> > following
> > />/ dmesg entry be the root of the problem?
> > />/ />/ cx25840 2-0044: cx25837-23 found @ 0x88 (pvrusb2_a)
> > />/ pvrusb2: Attached sub-driver cx25840
> > />/ />/ (It's similiar to the cs5345 message I posted earlier)
> > /
> > That message is fine.  That's just reporting that the cx25840 module has
> > successfully associated itself with the hardware and the pvrusb2 driver.
> >   
> Ok.
> It's just the mismatch of the addresses that caught my eye (in both cases): on
> the one hand 0x44 and on the other 0x88 (with the cs5345 it was 0x11 and
> 0x22). But I think the solution for this problem is simple: I don't know
> enough about v4l and/or i2c. ;)

Welcome to the world of I2C.  I2C addresses are 7 bits wide, with the 
8th bit indicating read/write.  Unfortunately there isn't a real 
standard for whether those addresses are printed left-justified or 
right-justified.  You're seeing both representations being used here.  
For the record, I normally think / handle I2C addresses right-justified, 
i.e. the range runs from 0x0 to 0x7f.


> 
> > >/ />/ I also opened my device and I didn't found a trace of a cs5345 (on
> > both sides
> > />/ of the board). At least if it is marked as one ^^.
> > /
> > I was only propagating what others have told me in the past about this
> > device.  If anything, your last message suggested the presence of a device
> > at I2C address 0x22.  So there's still something there that we're not
> > understanding.
> >   
> I know. This device is really mysterious... I think I'll open it once again
> and write down every chip name I can find in a little graphic. ^^
> 
> > >/ />/ Greetings,
> > />/ Sven
> > />/ />/ PS: My system hanged some minutes ago, while I used mplayer to play
> > from the
> > />/ video device and in parallel played music in moc... I will check if it
> > is an
> > />/ issue with your driver or just the "parallel"...
> > /
> > Well anything is possible...
> >   
> I kept it running two times for around one hour and no crash occured. But I
> didn't start moc again this time... Either it's really the two apps using the
> sound card or just a non deterministic hiccup ^^ I'll check again tomorrow
> with both applications running.

Sounds like a different issue.

The key issue here seems to be a problem with setup of audio routing in 
the cx25840 module.  We need to figure out if the module is correctly 
receiving the routing command from the pvrusb2 driver, and if it is 
reacting correctly to that command.  I'd like to think that it isn't 
receiving it correctly because then I can fix this problem from inside 
the pvrusb2 driver.

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8


More information about the pvrusb2 mailing list