On Fri, Nov 27, 2009 at 2:33 PM, Markus Rechberger <mrechberger at gmail.com> wrote: > On Fri, Nov 27, 2009 at 2:25 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: >> pe, 2009-11-27 kello 13:08 +0800, Markus Rechberger kirjoitti: >>> It works when the user is logged in or not. >>> The device supports TV (+Audio), and just simple FM Radio. >>> It is possible to remotely access this device (when configured to do so). >>> We're about to release a webfrontend for it so you can tune FM radio >>> through a website in your homenetwork (the network configuration needs >>> to be enabled explicitly by the user). >> >> These are my thoughts based on this description (they may not make sense >> if there are additional details that make things more complicated): >> >> The product should provide kernel drivers that create a few devices: for >> digital TV you provide a DVB device, for FM radio you provide an ALSA >> capture device, and if the device also does analog TV, I'm not sure how >> that is usually handled - is it a v4l device for video and an ALSA >> capture device for sound? >> > > it's entirely userspace based, as a second feature please note that we are able > to set up virtual devices (eg. streaming data from the network and > emulating devices) > So the audio input can either come from USB or from the network. > http://support.sundtek.com/index.php/topic,4.0.html maybe this can give an additional insight... Markus >> You apparently want to make sure that there are easy ways to actually >> use those devices, so you write some playback software that utilizes the >> standard DVB, v4l and ALSA interfaces that your kernel driver has >> provided. The user is free to use any other software instead of yours, >> thanks to the standard hardware interfaces. Your playback software >> shouldn't be tied in any way to your hardware, except for special >> hardware features that can't be exposed in a standard way (or if you >> really just don't want to make the software interoperable with other >> vendor's hardware). >> > > no it's a full virtual driver, it supports existing DVB and analog TV > applications, > The entire framework is based in userspace. > Linux multimedia support is currently quite a mess, default TV > applications across > all distributions mostly cannot handle audio by themself, this is why the driver > takes care about it. Aside of that when someone sets up FM radio through > the webinterface the daemon will run as root (either using a virtual > device through > the network or a physical one attached to the USB bus). > >> Let's consider local (non-networked) use first. In this case I don't see >> why your software should run as root. Provide a normal application that >> runs under the user that starts it. >> >> In the networked case your software needs to act as a server, and >> servers often are not associated with a user session. Here running as >> root makes sense, except that it doesn't - please run your server under >> a special-purpose user for security reasons. Anyway, here you're going >> to run into problems with PulseAudio. I think that reconfiguring >> PulseAudio to run in the system-wide mode makes sense, after notifying >> the user and offering a way to restore the configuration (I hope this is >> feasible). >> >> That's what I think, I'm not sure if it helps any... >> > > this is all just a workaround to ?fix something that pulseaudio > breaks.. I'd really > prefer to have something that works.. > When temporary changing over to the PA group the memory mappings > should be possible, > shouldn't it? I won't get around to check this before the end of next > week actually... > > PA could handle this in the PA simple library. The only exception that > has to be made > is for root and noone else.. > The topic should be how to fix pulseaudio instead of how to work > around the PA breakage. > > Markus >
