Re: USB Gadget driver for USB screen?

Sebastian Nielsen wrote: > Isn't the "Standard VGA card" appearing in device manager a standarized > device class? It was an ISA device. The PCI and PCI Express buses go to great lengths to be ISA compatible for VGA cards. USB is a different bus, and cannot be made compatible. Regards, Clemens

Re: USB Gadget driver for USB screen?

Sebastian Nielsen wrote: > Does anyone know of a USB Gadget kernel driver for a USB screen? There is no standardized device class for USB-to-VGA devices. > So I can have a linux USB gadget emulate as a USB screen to the host PC, and > aquire it's picture as a picture stream? You could try revers

Re: usb: usbtmc: Questions of the IVI Foundation

guido.kie...@rohde-schwarz.com wrote: > linux-usb-ow...@vger.kernel.org schrieb am 15.05.2017 15:20:22: >> Von: Greg KH >> On Mon, May 15, 2017 at 02:47:48PM +0200, Guido.Kiener@x wrote: >>> 2. As we have looked at the Linux driver, we’ve noticed that performance >>> of the usbtmc_read() f

Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack

Florian Fainelli wrote: > We see a large number of fixes to several drivers to remove the usage of > on-stack buffers feeding into USB transfer functions. Make it easier to spot > the offenders by adding a warning in usb_hcd_map_urb_for_dma() checking that > urb->transfer_buffer is not a stack obje

Re: [alsa-devel] Jack sensing in snd_usb_audio ?

Bastien Nocera wrote: > On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote: >> Bastien Nocera wrote: >>> " >>> A change of state in the audio function is most often caused by a >>> certain event that takes place. An event can either be user- &g

Re: [alsa-devel] Jack sensing in snd_usb_audio ?

Bastien Nocera wrote: > Looks like whether or not jack sensing works depends on the device > itself, but there is a mechanism to propagate the change in setup in > the USB Audio 2.0 spec Some recent Windows 10 beta added partial support for USB Audio 2.0. Earlier Windowses implement only USB Audio

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote: >> Windows does not have UAC2 support. > > Thanks, before windows7 or all windows versions have no UAC2 support? So far, no version has it. Regards, Clemens -- To unsubscribe from this list

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > I find UAC2 (UAC1 is ok) support is not well with the latest mainline > kernel w/o your patch set. The windows7 can't install the driver > successfully Windows does not have UAC2 support. > and the playback shows underrun (using local codec) > using Linux host. > # arecord -

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

Ruslan Bilovol wrote: > On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: >>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>> wrote: >>>>> it may break current usecase for some people >> >> And what are the benefits that jus

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >> wrote: >>> it may break current usecase for some people And what are the benefits that justify breaking the kernel API? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majo

Re: [PATCH] hwrng: alea - Add support for Araneus Alea I USB RNG

Bob Ham wrote: > Adds support for the Araneus Alea I USB hardware Random Number > Generator. This RNG creates entropy at a high rate, about 100kb/s. > > Signed-off-by: Bob Ham > --- > > +++ b/drivers/char/hw_random/alea.c Why didn't you just add the device ID to chaoskey.c? (Because that one is

Re: [PATCH] usb: core: Do not use sizeof on pointer type

Vaishali Thakkar wrote: > When sizeof is applied to a pointer typed expression, it gives > the size of the pointer. And why would that be wrong in this case? > +++ b/drivers/usb/core/hcd.c > @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus, > return -EFAULT; >

Re: Tascam US-122L - Corrupt USB descriptor

Simon Wood wrote: > On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote: >> Simon Wood wrote: >>> The card shows up under '/proc/asound/cards', but only as Midi. >> >> Apparently, there is no PCM device. This driver creates a special >> hardware-depe

Re: Tascam US-122L - Corrupt USB descriptor

Simon Wood wrote: > The card shows up under '/proc/asound/cards', but only as Midi. Apparently, there is no PCM device. This driver creates a special hardware-dependent device which is intended to be used with the Jack driver "usb_stream". It might be possible to use the ALSA "usb_stream" plugin:

Re: Tascam US-122L - Corrupt USB descriptor

Simon Wood wrote: > I have been struggling for the past few days to get a Tascam US-122L (USB > sound-card/midi interface) working, despite reading numerous forum > postings I have only been able to get the midi portion working. Does it show up with "aplay -l"? > I note that the USB descriptor se

Re: [PATCH v2 06/14] USB: ch341: reinitialize chip on reconfiguration

Grigori Goronzy wrote: > Changing the LCR register after initialization does not seem to be > reliable on all chips (particularly not on CH341A). Restructure > initialization and configuration to always reinit the chip on > configuration changes instead and pass the LCR register value directly > t

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Felipe Ferreri Tonello wrote: > On 11/03/16 23:07, Michal Nazarewicz wrote: >> I’m also wondering whether it would be beneficial to get rid of buflen >> all together and use wMaxPacketSie for in endpoints as well? Is that >> feasible? > > Yes, we could just remove the buflen parameter. > > The onl

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Steve Calfee wrote: > On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello > wrote: >> [...] >> This patch fixes this problem by setting the minimum usb_request's buffer >> size >> for the OUT endpoint as its wMaxPacketSize. >> >> --- a/drivers/usb/gadget/function/f_midi.c >> +++ b/drivers/usb/gad

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch > wrote: >> Felipe Ferreri Tonello wrote: >>> On 03/03/16 11:38, Clemens Ladisch wrote: >>>> But in what way was the old state machine not "proper"? >>&g

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 03/03/16 11:38, Clemens Ladisch wrote: >> But in what way was the old state machine not "proper"? > > Because it didn't reflect all the correct and possible MIDI states The whole point of the one-byte real-time messages is that the

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 02/03/16 21:09, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> This refactor results in a cleaner state machine code >> >> It increases the number of states, and now juggles two state variables. >> I cannot agree to it

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor results in a cleaner state machine code It increases the number of states, and now juggles two state variables. I cannot agree to it being cleaner. > and as a result fixed a bug when packaging a USB-MIDI packet right after > a non-conformant MIDI byte stre

Re: USB: gadget: add USB Audio Gadget driver

Alan Stern wrote: > On Sun, 31 Jan 2016, Clemens Ladisch wrote: >> Alan Stern wrote: >>> On Fri, 29 Jan 2016, Dan Carpenter wrote: >>>> The patch c6994e6f067c: "USB: gadget: add USB Audio Gadget driver" >>>> from Jun 3, 2009, leads to the follow

Re: USB: gadget: add USB Audio Gadget driver

Alan Stern wrote: > On Fri, 29 Jan 2016, Dan Carpenter wrote: >> The patch c6994e6f067c: "USB: gadget: add USB Audio Gadget driver" >> from Jun 3, 2009, leads to the following static checker warning: >> >> drivers/usb/gadget/function/f_uac1.c:371 f_audio_complete() >> error: __memcpy() '&

Re: [PATCH v7 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec

Dave Penkler wrote: > Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5) > and SRQ notifications with fasync (2/5) and poll/select (3/5) in order > to be able to synchronize with variable duration instrument > operations. > > Add convenience ioctl to return all device capabilitie

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: >> Running status is feature. > >What do you mean by that? That this behavior is intended, and required. > I don't qualify writing a *wrong* MIDI-USB >packet because of a previous MIDI message as a feature. The MIDI Specification qualifies Running Status as a featur

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor includes the following: > * Cleaner state machine code; It does not correctly handle system real time messages inserted between the status and data bytes of other messages. > * Reset state if MIDI message parsed is non-conformant; Why? In a byte stream

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > One thing to consider is that the ALSA rawmidi device buffer is > sequential and our USB request buffer is not. This means that our 32 > (qlen) * 256 (buflen) = 8KB of data is non-linear. Some requests might > have 3 or 4 bytes (average size of a normal MIDI message)

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > On 13/11/15 08:55, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> +static void f_midi_transmit(struct f_midi *midi) >>> +{ >>> +... >>> + len = kfifo_peek(&midi->in_req_fifo, &req);

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe F. Tonello wrote: > This patch introduces pre-allocation of IN endpoint USB requests. This > improves on latency (requires no usb request allocation on transmit) and avoid > several potential probles on allocating too many usb requests (which involves > DMA pool allocation problems). > > Thi

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe F. Tonello wrote: > This avoids duplication of USB requests for OUT endpoint and > re-enabling endpoints. > ... > /* For Control Device interface we do nothing */ > - if (intf == 0) > + if (intf != midi->ms_id) > return 0; The comment now is misleading. Regar

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe Ferreri Tonello wrote: > On 10/11/15 18:43, Sergei Shtylyov wrote: >> On 11/10/2015 08:52 PM, Felipe F. Tonello wrote: >>> @@ -75,6 +75,7 @@ struct f_midi { >>> struct usb_ep*in_ep, *out_ep; >>> struct snd_card*card; >>> struct snd_rawmidi*rmidi; >>> +

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> I believe that is the best way to implement. Create multiple requests >>> until the ALSA substreams buffer are empty and free the request on >>> comp

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> } else if (ep == midi->in_ep) { >>> - /* Our transmit completed. See if there's more to go. >>> -

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Balbi wrote: > Clemens Ladisch writes: >> Felipe Tonello wrote: >>> req->actual == req->length means that there is no data left to enqueue, >> >> This condition is not checked in the patch. >> >>> so free the request. >>> &g

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > req->actual == req->length means that there is no data left to enqueue, This condition is not checked in the patch. > so free the request. > > Signed-off-by: Felipe F. Tonello > --- > drivers/usb/gadget/function/f_midi.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 de

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

Peter Chen wrote: > I can't make my aplaymidi to receive data > # aplaymidi > open /dev/snd/seq failed: No such file or directory modprobe snd-seq There are mechanisms to load it automatically, but your embedded system might not bother about any of them. Or CONFIG_SND_SEQUENCER isn't enabled at

Re: USB bug

Andrew Gillis wrote: > Sep 17 10:07:38 sonicorbiter kernel: xhci_hcd :06:00.0: ERROR: unexpected > command completion code 0x11. This means that the USB controller does not like what the controller driver has told it to do. This could be a bug in some driver, but if it happens only with that

Re: tools: usbip: detach: avoid calling strlen() at each iteration

Aaro Koskinen wrote: > On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote: >> -for (unsigned int i = 0; i < strlen(port); i++) >> +unsigned int port_len = strlen(port); >> + >> +for (unsigned int i = 0; i < port_len; i++) > > port is read only in this function, so maybe just us

Re: USB bug

Andrew Gillis wrote: > I get an error when trying to play music through USB DACs under Linux. > This only happens with a few high end DACs and only when using a NEC > uPD72020x chipset USB 3.0 port. > > The people at RedHat think it may be the NEC uPD72020x chipset is > reporting it's capabilities

Re: MIDI gadget allocating too much from coherent pool

I wrote: > Felipe Tonello wrote: >> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB >> MIDI GADGET -> HOST >> >> When the throughput from the DSP is high, thus causing the throughput >> on the USB to be high as well, I get a Kernel Panic saying to increase >> the coherent_pool. I

Re: MIDI gadget allocating too much from coherent pool

Felipe Tonello wrote: > DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB > MIDI GADGET -> HOST > > When the throughput from the DSP is high, thus causing the throughput > on the USB to be high as well, I get a Kernel Panic saying to increase > the coherent_pool. I've used some cra

Re: external USB-Speaker and "Not enough bandwidth for altsetting 1"

Alan Stern wrote: > On Sun, 2 Aug 2015, Jakob Schürz wrote: >> P: Vendor=138a ProdID=003f Rev= 1.04 > > Do you happen to know what this device is? usb.ids says Validity Sensors VFS495 Fingerprint Reader. > Does it make any difference if you remove the Bluetooth radio and the > HP webcam? They c

Re: urb->interval differently interpreted via xhci for 2.0

(quoting fixed) Bernd Porr wrote: > Alan Stern wrote: >> On Wed, 24 Jun 2015, Bernd Porr wrote: >>> I use urb->interval to control the sampling rate of these devices. >>> That works fine with the ehci driver. When I use the xhci driver it >>> seems to be interpreting the urb->interval in a differe

Re: default/target product id /vendor id for usb devices

temp sha wrote: > I have a new usb dongle Huawei E3531 trying to support in my h/w > having old kernel version 2.6.16. > I use usb_modeswitch to change the mode from usb storage to modem > manually. As I do not have udev rule > support in my h/w, I need an alternative way of mode switching during >

Re: default/target product id /vendor id for usb devices

temp sha wrote: > Can any one brief me about the concept of default/target product id /vendor > id ? These are not terms that have a well-known meaning. Where did you hear them? And what is the actual problem you're trying to solve? Regards, Clemens -- To unsubscribe from this list: send the

Re: [PATCH] snd-usb-audio: Add support for Akai MPC Element MIDI controller

Paul Bonser wrote: > On 01/06/2015 07:39 AM, Clemens Ladisch wrote: >> Paul Bonser wrote: >>> This device incorrectly reports its bInterfaceClass as 255, when it >>> should really be 1 (USB_CLASS_AUDIO). >>> >>> +++ b/sound/usb/quir

Re: [PATCH] snd-usb-audio: Add support for Akai MPC Element MIDI controller

Paul Bonser wrote: > This device incorrectly reports its bInterfaceClass as 255, when it > should really be 1 (USB_CLASS_AUDIO). > > +++ b/sound/usb/quirks-table.h > +{ > + /* Akai MPC Element */ > + USB_DEVICE(0x09e8, 0x0021), > + .bInterfaceClass = USB_CLASS_AUDIO, > +}, This is not

Re: unfixable usb porthole

Gene Heskett wrote: > On Thursday 16 October 2014 18:28:16 Greg KH did opine > And Gene did reply: >> On Thu, Oct 16, 2014 at 06:12:48PM -0400, Gene Heskett wrote: >>> Is there a move afoot to write a checker utility that determines if >>> the usb device its pointed at is vulnerable, and can theref

Re: [gadget] Testing midi function

Andrzej Pietrasiewicz wrote: > I would like to try the midi function of usb gadget. > > Can anybody please tell me: > > 1) What userspace programs do I need at the gadget side? I've never used it, but as far as I can see, the MIDI function ends up as a normal sound card with MIDI port(s). Your de

Re: usb sound cannot get frequency from enpoind

vichy wrote: >> ALSA sound/usb/clock.c:237 2:3:1: cannot get freq at ep 0x82 >> ALSA sound/usb/mixer.c:929 5:2: cannot get min/max values for control 2 (id >> 5) >> ALSA sound/usb/mixer.c:929 5:2: cannot get min/max values for control 2 (id >> 5) > > (from the description, the ep 0x82 did have di

Re: [PATCH v6 5/5] usb: gadget: f_uac2: send reasonably sized packets

Daniel Mack wrote: > [...] > Please note, however, that you can't do the divison 'uac2->p_residue / > uac2->p_interval' in a pre-calucated value, as that won't cover cases > with a per-packet residual value that isn't a multiple of the frame > size. Partial frames are not allowed (neither in ALSA

Re: [PATCH 0/4] usb: gadget: f_uac2: cleanups and capture timing

Daniel Mack wrote: > a) Linux snd-usb-audio currently pre-calculates the estimated packet > sizes to expect from a USB device, and will only receive packets that > have the expected size or are smaller. snd-usb-audio allows packets to be 25 % larger. > This can be worked around by setting the UAC

Re: [PATCH] usb: use kcalloc instead of kzalloc

Arjun Sreedharan wrote: > kcalloc has protection from integer overflows > which could arise from the multiplication of > number of elements and size. You are implying that such an overflow could arise in this code. This is false. > @@ -380,8 +380,7 @@ static int usb_parse_interface(struct device

Re: Unknown USB IDs of Intenso Memory Box

Richard Hartmann wrote: > On Wed, May 14, 2014 at 10:14 AM, Clemens Ladisch wrote: >> Why? Is there a problem? > > No; it's working as expected. The implied statement was "the ids > should receive clear-text names". The device has clear-text names: idVe

Re: Unknown USB IDs of Intenso Memory Box

Richard Hartmann wrote: > I got two new Intenso 3.5" Memory Box with 3TB in the metallic edition > with USB 3.0 interface. > > Please see the attached output of `lsusb -vvv -d 2109:0701` Why? Is there a problem? > smartmontools doesn't seem to know that controller either It does not need to kno

Re: Fwd: Isochronos audio

Alan Stern wrote: > The IN transfer was 1 frame long and scheduled for frame 1123, so its > completion indicates that the current frame number is >= 1123. The OUT > transfer was 6 frames long and scheduled for frame , so it should > have completed in frame 1117. But the timestamps show that t

Re: OTG102/EzCapture2 no audio

David Woodfall wrote: > Success. I used the second command mentioned on the linuxtv wiki: > > mplayer tv:// -tv > driver=v4l2:device=/dev/video1:normid=8:alsa:adevice=hw.1:forceaudio:volume=80:immediatemode=0:width=720 > > Still no sound through arecord though. It's probably necessary to configure

Re: OTG102/EzCapture2 no audio

David Woodfall wrote: > mplayer reports no sound: > > mplayer tv:// -tv > driver=v4l2:device=/dev/video1:normid=8:alsa:adevice=hw.1:forceaudio:volume=80 > ... > Selected driver: v4l2 > Opening video decoder: [raw] RAW Uncompressed Video > Audio: no sound Does "mplayer something.wav" work? > Neit

Re: [alsa-devel] Fw: Isochronous transfer error on USB3

Mauro Carvalho Chehab wrote: > Clemens Ladisch escreveu: >> Mauro Carvalho Chehab wrote: >>> .period_bytes_min = 64, /* 12544/2, */ >> >> This is wrong (if the driver doesn't install other constraints on the >> period length, like the USB aud

Re: [alsa-devel] Fw: Isochronous transfer error on USB3

Mauro Carvalho Chehab wrote: > I'm getting an weird behavior with em28xx, especially when the device > is connected into an audio port. > > > http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c > > What happens is that, when

Re: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600

Takashi Iwai wrote: >> On Tue, 8 Oct 2013 baum...@hotmail.com wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=62691 >>> >>> Summary: no reset_resume for driver snd-usb-audio for logitech headset H600 > > How about simply applying the same resume for reset_resume like below? > > --- > > diff

Re: [alsa-devel] question about webcam audio capture

vichy wrote: > 2013/9/9 Clemens Ladisch : >> vichy wrote: >>> I try to do webcam audio capture on my arm platform. >>> when I execute audio capture I got below message >>> "retire_capture_urb: 108 callbacks suppressed" >> >> This me

Re: [alsa-devel] question about webcam audio capture

vichy wrote: > I try to do webcam audio capture on my arm platform. > when I execute audio capture I got below message > "retire_capture_urb: 108 callbacks suppressed" This means that the retire_capture_urb() function printed lots of messages, and that 108 of them were thrown away because they wer

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: > On Tue, 27 Aug 2013, Clemens Ladisch wrote: >> Alan Stern wrote: >>> On Tue, 27 Aug 2013, Clemens Ladisch wrote: >>>> The current algorithm uses very short capture URBs to ensure that _some_ >>>> URB is completed as soon as possibl

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: > On Tue, 27 Aug 2013, Clemens Ladisch wrote: >> The current algorithm uses very short capture URBs to ensure that _some_ >> URB is completed as soon as possible after a period ends. >> [...] >> I'd suggest to keep the old calculation for capture

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Pavel Hofman wrote: > On 27.8.2013 09:19, Clemens Ladisch wrote: >> The driver cannot control how many samples actually end up in a capture >> packet,... > > Does this reasoning apply to asynchronous playback too? No. > I understand the driver has some control, but has

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: >> All the difficulty arises from the fact that we don't know beforehand >> how many URBs will constitute an ALSA period since for playback >> endpoints, the URB sizes can vary. [...] >> the number of URBs per period is fixed, and the number of packets in >> each URB is adjusted

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: > On Tue, 13 Aug 2013, Clemens Ladisch wrote: >>> The difference is that this version tries always to keep a period's >>> worth of bytes in the USB hardware queue. >> >> Having truncated URBs is possible only when URBs are shorter than one

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: > On Mon, 12 Aug 2013, Alan Stern wrote: >> Here's a revised version of the patch (still untested). The difference >> is that this version tries always to keep a period's worth of bytes in >> the USB hardware queue. This will provide better protection against >> underruns when t

Re: [alsa-devel] Buffer size for ALSA USB PCM audio

Alan Stern wrote: > On Mon, 12 Aug 2013, Takashi Iwai wrote: >> So... Clemens, Daniel, Eldad, could you guys review the latest version >> of Alan's patch? I'd love to sort this out for 3.12. > > Here's a revised version of the patch (still untested). > - maxsize = ((ep->freqmax + 0x) * (f

Re: [alsa-devel] [PATCH] 6fire: fix URB transfer buffer for midi output

Takashi Iwai wrote: > Alan Stern wrote: >> A buffer _can_ be in the middle of a kmalloc'ed space, but the CPU must >> not access any of the fields around it that might occupy the same cache >> line while the buffer is being used for DMA. > > Hrm, but does the kmalloc buffer always guarantee such ca

Re: Audio I/O parameters

Alan Stern wrote: > On Thu, 1 Aug 2013, Clemens Ladisch wrote: >>> It seems likely that the error is caused by an SMI taking too much >>> time. At least, we seem to have ruled out everything else. Besides, >>> this change has to be made eventually in any case --

Re: [PATCH] usb: gadget: audio file: wake up sleep thread when device unbind

Qiao Zhou wrote: > when usb audio device removes, it doesn't notify the ALSA read / > write thread. due to no data transmitting any more, those threads > wait for a long timeout(10s), then detects IO error. it causes > long time blocking in upper layer read/write. > > to fix this issue, wake up pot

Re: Audio I/O parameters

Alan Stern wrote: > On Wed, 31 Jul 2013, James Stone wrote: >> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern >> wrote: >>> James, see what happens with this patch. It will print a warning >>> message in the system log every time it detects an underrun, but it >>> won't cause an URB submission fail

Re: Buffer size for ALSA USB PCM audio

Alan Stern wrote: > Clemens remarked some time ago that keeping the queue full would be > trivial, if only he knew how full it needed to be. The answer to that > is given above. I have been trying to make the appropriate changes, > but I'm not finding it "trivial". What I meant was that it would

Re: Audio I/O parameters

Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: >> The only slight difference I can see is that maybe the 3.10 uses >> slightly higher CPU load than 3.5 at the ridiculously low latency of >> 64 frames/period duplex. > > With the new patch, what you actually get is 44.1 frames/period (on

Re: Audio I/O parameters

James Stone wrote: > On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote: >> The commit that you found by bisection got reverted later: >> <http://git.kernel.org/linus/015618b902ae> >> >> Please check that the code of "Fix URB cancellation at stream start&q

Re: Audio I/O parameters

James Stone wrote: > Ok -from the bisect, the problem of not being able to get to sub > 64-frames per period starts with: > > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 This is a merge, which includes this commit:

Re: Sound Blaster USB X-Fi configuration problem

Alan Stern wrote: > On Sat, 20 Jul 2013, Mariusz Grecki wrote: >> +u16 buf = 1; >> + >> +snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a, >> +USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, >> +0, 0, &buf, 2); > > There's a serious problem here. I

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Fri, Jul 19, 2013 at 5:06 PM, Clemens Ladisch wrote: >> Ming Lei wrote: >>> if (list_empty (&stream->td_list)) { >>> if (running from hcd interrupt or tasklet context) >>> underrun >>> else >>>

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Fri, Jul 19, 2013 at 1:44 AM, Clemens Ladisch wrote: >> In any case, there must be _some_ mechanism to explicitly restart >> a stream. I do not really care if this is some URB flag or some >> function call. > > Thought about the problem further,

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Fri, Jul 19, 2013 at 5:20 AM, Alan Stern wrote: >> On Thu, 18 Jul 2013, Clemens Ladisch wrote: >>> In any case, there must be _some_ mechanism to explicitly restart >>> a stream. I do not really care if this is some URB flag or some >>

Re: How should we handle isochronous underruns?

Alan Stern wrote: > On Thu, 18 Jul 2013, Ming Lei wrote: >> On Thu, Jul 18, 2013 at 3:24 AM, Alan Stern >> wrote: >>> On Thu, 4 Jul 2013, Alan Stern wrote: On Thu, 4 Jul 2013, Ming Lei wrote: >>> I had some more ideas about this. Instead of requiring drivers to set >>> URB_ISO_ASAP on just

Re: Audio I/O parameters

Alan Stern wrote: > The audio-out stream uses a pipeline of only 2 URBs. The URBs start > out alternating between 8 and 7 packets apiece. This yields a total > latency around 1.9 ms (equivalent to 2 periods of about 41 frames at > 44.1 KHz), which is smaller than I would expect (2 periods of 64 f

Re: Audio I/O parameters

Alan Stern wrote: > On Sat, 13 Jul 2013, Clemens Ladisch wrote: >> James Stone wrote: >>> On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: >>>>> configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods >>>>> JackAudioDriver::Proc

Re: Audio I/O parameters

James Stone wrote: > On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: >>> configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods >>> JackAudioDriver::ProcessAsync: read error, stopping... >> >> Some further info - on 3.5.0-28, I can start jackd in playback only >> with 8 frames

Re: Audio I/O parameters

James Stone wrote: > On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: >>> ALSA: poll time out, polled for 2176094 usecs >>> JackAudioDriver::ProcessAsync: read error, stopping... >>> >>> This is a definite reduction in performance compared to earlier kernels. In theory, "poll time out" indicate

Re: Audio I/O parameters

Alan Stern wrote: > The first half is audio-out only. About 2 seconds after the start, the > audio-in stream starts up. After 2 URBs (2 ms) of data, everything > is shut down for no apparent reason -- there were no I/O errors. > [...] > I can't tell whether all these starts and stops are caused b

Re: How should we handle isochronous underruns?

Alan Stern wrote: > On Thu, 4 Jul 2013, Ming Lei wrote: >>> Changing the altsetting is another way to tell the HCD that a stream is >>> starting fresh. >> >> Yes, it might work, but many details need to be payed attention to, such >> as, changing altsetting may not be done during suspend/resume. >

Re: Audio I/O parameters

ould result in URBs with far too few packets, which would not work correctly on the EHCI driver. To get correct URBs, use wMaxPacketSize only as an upper limit on the packet size. Reported-by: James Stone Not-yet-tested-by: James Stone Cc: # 2.6.35+ Signed-off-by: Clemens Ladisch --- sound/us

Re: Audio I/O parameters

Alan Stern wrote: >256 samples/period / (44100 samples/second) * 8000 microframes/second > = 46.44 microframes/period. > > Therefore I would expect to see snd-usb-audio submitting isochronous > URBs with 46 or 47 packets, with a pipeline depth of 2 URBs. > > However, that's not what actua

Re: How should we handle isochronous underruns?

Alan Stern wrote: > (1) Reject the submission with -EXDEV -- this is what we do now. > > (2) Accept the submission, but have the URB complete immediately > with urb->status and all the packet statuses set to -EXDEV. > > (3) Accept the submission, but have the URB complete immediat

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Mon, Jul 1, 2013 at 9:27 PM, Clemens Ladisch wrote: >> Ming Lei wrote: >>> On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch wrote: >>>> Ming Lei wrote: >>>>> I understand the latency is effected by packet count in one URB, >

Re: How should we handle isochronous underruns?

Pratyush Anand wrote: > On 7/1/2013 4:48 PM, Clemens Ladisch wrote: >>> There is no meaning of submitting an URB for expired time slot. >> >> Of course there is. The HCD cannot exactly know whether the current >> slot will expire before the URB is enqueued, so i

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch wrote: >> Ming Lei wrote: >>> I understand the latency is effected by packet count in one URB, >>> and it shouldn't be related with URB count, >> >> This is true only when capturing. F

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern > wrote: >> Naturally, under normal circumstances this won't matter, because >> underruns shouldn't occur. But I know from experience that people try >> to push the latency as far down as they can, which increases the >> likelihood o

Re: How should we handle isochronous underruns?

Ming Lei wrote: > On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern > wrote: >> Thus, for example, even if the pipeline contains only a single URB, >> with the current code it will not become empty. But with the new code >> it will. If the load on the system is too high, the pipeline could >> empty

Re: How should we handle isochronous underruns?

Pratyush Anand wrote: > On 6/30/2013 8:32 PM, Alan Stern wrote: >> It could schedule the URB for the first time slot known to be >> available, even if that means skipping some time slots which >> the hardware might (or might not) be able to use. > > IMO, this approach is better. To quo

Re: How should we handle isochronous underruns?

Alan Stern wrote: > [...] > This means that the HCD will have trouble telling the difference > between an underrun and a normal restart of a stopped I/O stream. In > both cases it will see an URB being submitted to an empty queue. > Here's where the URB_ISO_ASAP flag will be useful; if that flag i

  1   2   >