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,

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

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

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

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

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 <clem...@ladisch.de> wrote: >>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>> <ruslan.bilo...@gmail.com> wrote: >>>>> it may break current usecase for some people

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

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

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-dependent

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"

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

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 >

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

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

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 <clem...@ladisch.de> > wrote: >> Felipe Ferreri Tonello wrote: >>> On 03/03/16 11:38, Clemens Ladisch wrote: >>>> But in what way was the old state machine not "pr

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 they

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

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

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

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

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

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(>in_req_fifo, ); >>

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 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.

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). > >

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 <clem...@ladisch.de> wrote: >> Felipe Tonello wrote: >>> } else if (ep == midi->in_ep) { >>> - /* Our transmit

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 <clem...@ladisch.de> 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 r

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

Felipe Balbi wrote: > Clemens Ladisch <clem...@ladisch.de> 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

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

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

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

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

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

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.

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: 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 compete

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 different way and/or

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/quirks-table.h +{ + /* Akai MPC Element */ + USB_DEVICE(0x09e8, 0x0021

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 a

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 therefore be

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 device

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 different

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 nor in

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

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: 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 know the

Re: Unknown USB IDs of Intenso Memory Box

Richard Hartmann wrote: On Wed, May 14, 2014 at 10:14 AM, Clemens Ladisch clem...@ladisch.de 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: idVendor 0x2109

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 the

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? Neither aplay

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 the

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 I

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

Mauro Carvalho Chehab wrote: Clemens Ladisch clem...@ladisch.de 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 audio class driver does). Ok, how

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 --git

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 were

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

vichy wrote: 2013/9/9 Clemens Ladisch clem...@ladisch.de: 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

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 during

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 to satisfy the endpoint feedback

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 URBs. It would make sense to use longer

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 period, No. URBs are truncated when a full

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 the

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) *

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 cache line

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 st...@rowland.harvard.edu 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

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

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 -- underruns can occur at any time

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: 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: 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 is in your current kernel. well, in 3.10

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. It's present

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Fri, Jul 19, 2013 at 5:20 AM, Alan Stern st...@rowland.harvard.edu 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 function call. I prefer

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Fri, Jul 19, 2013 at 1:44 AM, Clemens Ladisch clem...@ladisch.de 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, looks there is one

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Fri, Jul 19, 2013 at 5:06 PM, Clemens Ladisch clem...@ladisch.de wrote: Ming Lei wrote: if (list_empty (stream-td_list)) { if (running from hcd interrupt or tasklet context) underrun else new stream } Why shouldn't a driver start a stream

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 st...@rowland.harvard.edu 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

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

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 jamesmst...@gmail.com wrote: configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods JackAudioDriver::ProcessAsync: read error, stopping... Some

Re: Audio I/O parameters

James Stone wrote: On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com 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

Re: Audio I/O parameters

James Stone wrote: On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com 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

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 by

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. Hmmm. I

Re: Audio I/O parameters

-off-by: Clemens Ladisch clem...@ladisch.de --- sound/usb/endpoint.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 7a444b5..659950e 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -591,17 +591,16

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 actually

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 quote the

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu 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

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu 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

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de 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. For playback, the latency is the length

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 it is not always possible to label the slot

Re: How should we handle isochronous underruns?

Ming Lei wrote: On Mon, Jul 1, 2013 at 9:27 PM, Clemens Ladisch clem...@ladisch.de wrote: Ming Lei wrote: On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de wrote: Ming Lei wrote: I understand the latency is effected by packet count in one URB, and it shouldn't be related

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 immediately

Re: Sound Blaster USB X-Fi configuration problem

Mariusz Grecki wrote: Does anybody have any idea what can be the problem? The card is recognized as HS device by MS Windows (XP version) without any exceptions... When you say Windows, do you mean Windows itself, or a driver from Creative that you installed and that can send some

Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

Alan Stern wrote: It is now unnecessary to set urb-start_frame; in fact that field is now output-only. (To be fair, I haven't checked _all_ the HCDs in this regard, just uhci-hcd, ohci-hcd, and ehci-hcd. However, if any other HCD requires urb-start_frame to be set then that HCD should be

Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

Alan Stern wrote: On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One

  1   2   >