Re: [PATCH] cx88-dvb.c: DVB net latency using Hauppauge HVR4000

2010-12-26 Thread Heino Goldenstein
Hello,

Am Freitag, 24. Dezember 2010 20:28 schrieb Goga777:

 will your patch useful for dvb sat tv ?

   We are from School On Internet Asia (SOI Asia) project that uses
  satellite communication to deliver educational content. We used Hauppauge
  HVR 4000 to carry IP traffic over ULE. However, there is an issue with
  high latency jitter. My boss, Husni, identified the problem and provided
  a patch for this problem. We have tested this patch since kernel 2.6.30
  on our partner sites and it hasn't cause any issue. The default buffer
  size of 32 TS frames on cx88 causes the high latency, so our deployment
  changes that to 6 TS frames. This patch made the buffer size tunable,
  while keeping the default buffer size of 32 TS frames unchanged. Sorry, I

FWIW in the DVBlast subversion is a similar patch [1] touching the same
value. See the reason for this in the README [2].

Tjuess
  Heino

[1]http://svn.videolan.org/filedetails.php?repname=DVBlastpath=%2Ftrunk%2Fextra%2Fkernel-patches%2F03-cx88.patch
[2]http://svn.videolan.org/filedetails.php?repname=DVBlastpath=%2Ftrunk%2Fextra%2Fkernel-patches%2FREADME
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] FM Transmitter driver

2009-04-04 Thread Heino Goldenstein
Hello,
Am Freitag, 3. April 2009 12:12 schrieb Eduardo Valentin:
 On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote:
  On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote:
   Hi Hans,
  
   On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote:
On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote:
 Hello Mauro and v4l guys,

 This series contains a v4l2 radio driver which
 adds support for Silabs si4713 devices. That is
 a FM transmitter device.

 As you should know, v4l2 does not contain representation
 of FM Transmitters (at least that I know). So this driver
 was written highly based on FM receivers API, which can
 cover most of basic functionality. However, as expected,
 there are some properties which were not covered.
 For those properties, sysfs nodes were added in order
 to get user interactions.

 Comments are wellcome.
   
Can you explain in reasonable detail the extra properties needed for
a device like this? You will need to document that anyway :-) Rather
than implementing a private API it would be much more interesting to
turn this into a public V4L2 API that everyone can use.
  
   Yes, here is a little description of them:
  
   Pilot is an audible tone sent by the device.
  
   pilot_frequency - Configures the frequency of the stereo pilot tone.
   pilot_deviation - Configures pilot tone frequency deviation level.
   pilot_enabled - Enables or disables the pilot tone feature.
  
   The si4713 device is capable of applying audio compression to the
   transmitted signal.
  
   acomp_enabled - Enables or disables the audio dynamic range control
   feature. acomp_gain - Sets the gain for audio dynamic range control.
   acomp_threshold - Sets the threshold level for audio dynamic range
   control. acomp_attack_time - Sets the attack time for audio dynamic
   range control. acomp_release_time - Sets the release time for audio
   dynamic range control.
  
   Limiter setups audio deviation limiter feature. Once a over deviation
   occurs, it is possible to adjust the front-end gain of the audio input
   and always prevent over deviation.
  
   limiter_enabled - Enables or disables the limiter feature.
   limiter_deviation - Configures audio frequency deviation level.
   limiter_release_time - Sets the limiter release time.
  
   power_level - Sets the output power level for signal transmission.
 
  Hmm, there are two ways to implement these: either make a bunch of
  VIDIOC's for each of these categories, or use extended controls to set
  all these values. I'm hardly an expert on FM transmitters, but it all
  seems reasonable to me (i.e., not too specific for this chip).
 
  I am leaning towards extended controls, since that's so easy to extend if
  needed in the future. And I still intend to add sysfs support to controls
  in the future. On the other hand, it's a bit harder to use compared to
  normal VIDIOCs.

 Could you please explain more about extended controls vs. VIDIOC's?
 Pointing drivers which uses one of those also would be worth. But yes,
 looks like moving this properties to some sort of v4l2 control looks better
 implementation.

   RDS related
  
   rds_enabled - Enables or disables the RDS feature.
   rds_ps_name - Sets the RDS ps name field for transmission.
   rds_radio_text - Sets the RDS radio text for transmission.
   rds_pi - Sets the RDS PI field for transmission.
   rds_pty - Sets the RDS PTY field for transmission.
 
  So you set the fields and the RDS encoder will just start using them?

 Once you have rds_enabled set, yes, it will transmit them.

  This too can be done with controls (needs some work, though, to support
  string controls).

 Yes, true.

   Region related
  
   Setting region will affect other region properties.
  
   region_bottom_frequency
   region_channel_spacing
   region_preemphasis
   region_top_frequency
 
  I do not know enough about FM transmissions to judge this. Are these
  region properties something that is regulated by some standards
  commision? Do they also apply when you modulate this over a TV/radio
  cable system? Do you have some documentation or links that I can look at
  to learn more about this?
 
   stereo_enabled - Enables or disables stereo mode.
  
How does one pass the audio and rds data to the driver? Note that for
2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted
an RFC for that, but I haven't had the time to implement the few
changes needed). It would be nice if rds modulator support would be
modeled after this demodulator API if possible.
  
   I see. This is good. I think the best way is to have a rds modulator
   interface. This driver have implemented it as sys properties, as
   described above.
 
  I don't think there is that much overlap, though. The similarities are
  probably limited to some flags.
 
Does region information really belong in the driver? Perhaps