From: Antti Palosaari <crope@iki.fi>
To: linux-media <linux-media@vger.kernel.org>
Subject: Re: DVB USB: change USB stream settings dynamically
Date: Sun, 27 May 2012 16:10:31 +0300 [thread overview]
Message-ID: <4FC227C7.3080309@iki.fi> (raw)
In-Reply-To: <4FC00C11.10403@iki.fi>
On 26.05.2012 01:47, Antti Palosaari wrote:
> I was planning make DVB USB be able to switch USB streaming parameters
> dynamically. I mean [struct usb_data_stream_properties] parameters.
>
> Currently it reserves USB streaming buffers when device is plugged. Own
> buffer is reserved for each frontend, which means currently 1-3
> streaming buffers depending on device.
>
> Basically I see USB TS as a DVB USB device property - not property of
> frontend. USB TS is interface between computer and USB-bridge and amount
> of parallel USB TS or TS configurations depends on USB-bridge
> capabilities. Sometimes used USB TS could be configured to fit better
> used stream. Smaller buffers for the narrow radio stream and biggest
> buffers for the wide DVB-S2 stream.
>
> I was wondering how to resolve that situation? It is not very big
> problem currently but I still want to make it better as there is surely
> coming new devices that needs better control for the USB streaming
> parameters. Currently there is mxl111sf driver which seems to offer 6
> different streaming configurations but AFAIK only three is currently
> used as there is 3 frontends and each one has own streaming parameters -
> and buffers - even only one can be used at the time.
>
> 1. Configure streaming parameters (alloc buffers) every time when
> streaming is started? IIRC that causes some problems lately for em28xx
> as memory goes dis-coherent and buffers cannot allocated.
>
> 2. Allocate buffers (streaming configuration) for all needed device use
> configurations at very beginning. Then add some logic to map streaming
> config to frontend at runtime. That is quite near what mxl111sf does
> currently.
After looking existing code carefully and doing some tests I think I
will implement that a way it changes buffers at runtime to fit current
needs.
int usb_urb_submit(struct usb_data_stream *stream) is called when
streaming is started. At that point it is possible to compare already
reserved buffers and buffers needed. If needed buffers are larger it is
possible to reallocate bigger buffers. Of course it is not needed to
decrease buffers even smaller stream configurations is asked, just to
avoid repetitive allocations of large chunks of coherent memory.
1) allocate buffers at the init as now (callback to read stream
properties from the driver)
2) re-allocate bigger buffers in runtime if needed (callback to read
stream properties from the driver)
3) free all buffers when device is disconnected
Basically those USB buffers are type of (buffer count) x (buffer size).
Buffer count is same as used count of URBs, typically ~5, and buffer
size is the payload size of one URB.
Here is some background info (em28xx buffer alloc failures) why to avoid
continuous buffer allocs / frees.
http://www.spinics.net/lists/linux-media/msg44209.html
regards
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2012-05-27 13:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 22:47 DVB USB: change USB stream settings dynamically Antti Palosaari
2012-05-27 13:10 ` Antti Palosaari [this message]
2012-05-27 16:43 ` Gianluca Gennari
2012-05-27 23:40 ` Antti Palosaari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC227C7.3080309@iki.fi \
--to=crope@iki.fi \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.