[pvrusb2] remote, radio and other issues

Mike Isely isely at isely.net
Tue Feb 27 23:42:30 CST 2007


On Tue, 27 Feb 2007, leonardo wrote:
> 
> thanks for the clear explaination. 

> This is the same problem of having  a  MPEG output  and making TV applications read it,
>  right?  how do those application deal with DVB?

Yes, same sort of issue.

DVB is an API that "natively" speaks MPEG.  So anything which is DVB 
compatible must therefore know how to grok an mpeg stream.


> maybe this has been already discussed in the past for video, but wouldn't it be 
> convenient to embed into the code of the driver itself  the creation of a new device
> that outputs a pcm stream? Even if I'm no expert of low level development 
> I understand that encoding/decoding in kernel space is not a clean solution
> but it would make the device "standard" to what V4L expects, withouth requesting 
> the user to mess around with mplayer&co and without changing V4L (which should be
> the most proper action as I understand). What would be the pros and cons of this
> solution?

Well that's easier said than done.  As you suspect, this sort of thing 
kind of gets out of the scope of the driver.  I'm not completely against 
something like this, but it is a complicated thing to do (essentially 
we're talking about mp3 decoding in kernel space - yuck), it only 
benefits the pvrusb2 driver (i.e. it should be more generally 
available), and it's logic that really belongs in userspace.  Now, if on 
the other hand we could get the hardware to just spit out PCM data then 
of course it would make sense to make that available in the driver.  
But right now we haven't gotten that sort of thing working.  There are 
some tantalizing clues to suggest this could be made to work but so far 
this hasn't happened yet.

Interesting point about making the device "standard" with respect to 
V4L.  However there really "isn't" a standard here in V4L with respect 
to audio.  Honestly V4L shouldn't have to deal with audio on its own.  
I mean, isn't that the whole point behind ALSA?...  (But ideally there 
isn't an ideal solution here - while a V4L device that dumps out PCM is 
an obvious candidate for having an ALSA capture interface, the picture 
gets a lot cloudier if we're talking about a combined video / audio 
stream like mpeg data.)

  -Mike


-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |


More information about the pvrusb2 mailing list