summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/uaudio.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Set the length of isochronous transfers as the sum of the frames lengths.mpi2015-06-151-11/+7
| | | | | | | | | | | | This reduces differences between non-isoch and isoch transfers submissions, makes the generic DMA buffer overrun check work with isoch transfers and will allow some code simplifications in HC drivers. Since short-transfers were never checked for isoch transfers, we now need to pass the USBD_SHORT_XFER_OK flag to not change this behavior. This might be revisited later. ok ratchov@
* Remove all audio format conversion code from the kernel (btw holdingratchov2015-05-111-7/+1
| | | | | | | | | the kernel_lock), as we already do better conversions in user-mode. Yet, no need for every single driver to fiddle with the conversion code as they are done transparently by common MI code. With help from armani and miod, support from mpi ok armani@
* Remove some includes include-what-you-use claims don'tjsg2015-03-141-2/+1
| | | | | | | have any direct symbols used. Tested for indirect use by compiling amd64/i386/sparc64 kernels. ok tedu@ deraadt@
* pretty up some malloc() callsderaadt2015-01-121-3/+4
|
* yet more mallocarray() changes.doug2014-12-131-5/+8
| | | | ok tedu@ deraadt@
* More malloc() -> mallocarray() in the kernel.doug2014-12-091-10/+10
| | | | ok deraadt@ tedu@
* Nuke yet more obvious #include duplications.krw2014-11-181-2/+1
| | | | ok miod@
* Now that DVACT_DEACTIVATE is propagated to the children of a device whenmpi2014-08-211-28/+5
| | | | | | a driver does not implement a specific *_activate() handler and that our USB stack sets the dying flag before detaching a device, these specific handlers can die.
* add a size argument to free. will be used soon, but for now default to 0.tedu2014-07-121-13/+13
| | | | after discussions with beck deraadt kettenis.
* Properly compare endpoint addresses: ignore the direction bit whichratchov2014-06-041-2/+3
| | | | | | | is not part of the address. From Remco <remco at d-compu.dyndns.org>, thanks! ok mpi@
* fix format mistakes visible if UAUDIO_DEBUG is definedratchov2014-05-171-3/+3
|
* Replace sc_dying in favour of usbd_is_dying() and usbd_deactivate().pirofti2013-11-061-15/+14
| | | | Okay mpi@
* Introduce a global interrupt-aware mutex protecting dataratchov2013-05-151-7/+6
| | | | | | | | | | | | | structures (including sound-card registers) from concurent access by syscall and interrupt code-paths. Since critical sections remain the same, calls to splraise/spllower can be safely replaced by calls to mtx_enter/mtx_leave with two exceptions: (1) mutexes are not reentrant (the inner splraise is thus removed), and (2) we're not allowed to sleep with a mutex (either msleep is used or the mutex is released before sleeping). ok and help from kettenis, a lot of work from armani
* Get rid of various 'typedef struct' definitions and use plain structuremglocker2013-04-151-18/+18
| | | | | | | | | definitions instead. We don't change usb.h for now to stay compatible with userland. Tested by mpi@ on macppc and myself on i386. ok mpi@
* proc.h is way too much header for usb to handle.tedu2013-03-281-2/+1
|
* you probably don't need to include vnode.h or reboot.h. you most definitelytedu2013-03-281-9/+7
| | | | | absolutely do not need to include vnode.h because it includes uvm_extern.h and you want the idiotic TRUE FALSE defines from uvm.
* use UE_GET_ADDR to get endpoint address (remove direction bit). Fixesratchov2012-03-011-2/+3
| | | | | devices using sych endpoints. From Gregor Pintar <grpintar at gmail.com> Thanks!
* add uhid/uaudio quirks for the iPad and iPad 2.brynet2012-01-311-1/+5
| | | | ok deraadt@/dcoppa@ and sthen@.
* Don't printf (recoverable) xruns unless UAUDIO_DEBUG is definedratchov2012-01-261-2/+2
|
* Mark Apple iPod and iPhone products with UQ_BAD_HID and UAUDIO_FLAG_BAD_AUDIO.dhill2011-12-011-1/+21
| | | | | | | This allows these devices to attach as ugen, so at least we can use some apps, like gphoto2 to retrieve media. requested by a few, ok mikeb@
* Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thingmatthew2011-07-031-3/+1
| | | | | | | | that's ever used it, and it's long since been changed to use DVACT_{QUIESCE,SUSPEND,RESUME} instead. ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it up a few weeks ago
* garbage collect "usb events". without /dev/usb there is no way to accessjakemsr2011-01-251-7/+1
| | | | | | them from userland, and nothing in the kernel uses them. ok krw@, miod@
* * instead of NULLing pointers to interface descriptors in the uaa, markjakemsr2011-01-161-5/+3
| | | | | | | | | | | | | interfaces as being claimed in the usbd_device's copy of the interface descriptors * allow ugen(4) to be attached if there are unused interfaces in a configuration that has had drivers attached * make ugen(4) aware that it may be sharing a device with (an)other driver(s), and if so: * do not let ugen(4) change the configuration * do not let ugen(4) access the already claimed interfaces discussed with deraadt and miod
* * indentation fixjakemsr2010-08-181-3/+3
| | | | * use the correct variable in a DPRINTF
* * the detach and drain functions do the same waiting for channels tojakemsr2010-08-181-12/+12
| | | | | complete outstanding requests, so use uaudio_drain in uaudio_detach. * the channel alt index can still be -1 at detach. check for this.
* check for audio stream and control interface descriptors in thejakemsr2010-07-311-16/+38
| | | | | | device configuration descriptor in the match() function. stops midi devices from attaching as uaudio then bailing out, leaving a phantom uaudio.
* bring back changes in uaudio.c r1.83, this time remembering to commitjakemsr2010-07-231-65/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | uaudioreg.h. sorry about that. sync endpoints allow for the sample clock on USB audio devices to not be synchronized to the USB clock. the sync endpoint gives information on how much data to send to the data endpoint. although devices that require sync endpoints will "work" when the sync endpoint inormation is ignored, there is a possibility of static, echoing, or any other type of clock desync error. requires some small changes to existing code: * tighten up checks for whether a setting needs/supplies a sync endpoint. ignore settings that need a sync endpoint but don't supply one. previously all settings that require a sync endpoint were ignored. * if a sync endpoint is being used, use the same denominator for fractional samples as the sync endpoint uses (2**16). this only implements playback sync endpoints. recording sync endpoints are an odd concept: the driver would control the clock rate of the device. there may be such devices, but I can't even imagine how that could be reliably implemented. I guess you would sync to the USB clock or the system clock ... but then, what's the point?
* revert last commit, unbreaking the tree; was missing a macro definitionsthen2010-07-231-230/+65
| | | | presumably from a missing commit to a header file. go ahead kettenis@ todd@
* support for playback sync endpointsjakemsr2010-07-231-65/+230
| | | | | | | | | | | | | | | | | | | | | | | | sync endpoints allow for the sample clock on USB audio devices to not be synchronized to the USB clock. the sync endpoint gives information on how much data to send to the data endpoint. although devices that require sync endpoints will "work" when the sync endpoint inormation is ignored, there is a possibility of static, echoing, or any other type of clock desync error. requires some small changes to existing code: * tighten up checks for whether a setting needs/supplies a sync endpoint. ignore settings that need a sync endpoint but don't supply one. previously all settings that require a sync endpoint were ignored. * if a sync endpoint is being used, use the same denominator for fractional samples as the sync endpoint uses (2**16). this only implements playback sync endpoints. recording sync endpoints are an odd concept: the driver would control the clock rate of the device. there may be such devices, but I can't even imagine how that could be reliably implemented. I guess you would sync to the USB clock or the system clock ... but then, what's the point?
* add a couple quirks for the E-MU 0202jakemsr2010-07-211-4/+39
| | | | | | | | | * the clock rate is configured through the audio interface, instead of on the endpoint. * since the clock rate is set on the interface, both play and record must use the same sample rate. this means the playback and recording parameters are not independent, which is what uaudio assumes.
* * check that the bytes per frame the device is reporting isn't ajakemsr2010-07-211-6/+7
| | | | | ridiculous value. * encoding expansion factor is always 1.
* move use_maxpkt out of struct chan, use a local variable in thejakemsr2010-07-211-8/+6
| | | | only function that was using it.
* some bits for USB 2.0 playback support. I'm not 100% sure aboutjakemsr2010-07-211-4/+23
| | | | | | | | scaling the frame rate to the polling interval, but it works on the E-MU 0202 and it generally makes a lot of sense, especially considering that this often brings the frames rate back to 1 kHz, which is the frame rate of USB 1.x, which was the most current USB spec when USB audio 1.0 spec was written.
* currently we use the endpoint's maximum packet size for recording,jakemsr2010-07-211-21/+48
| | | | | | | | | | | | | | | | | | | | and for playback, we use a packet size that is at least one audio frame smaller. in most usb audio devices, the sample clock is synced to the usb clock. this means that for sample rates that aren't multiples of 1000, we'll occasionally need to add a frame to adjust the overall rate. that's why we use the smaller packet size. also, the usb audio spec defines a way for devices to request to always use the maximum packet size. so, * add a max_bytes_per_frame, which is the largest packet size the channel will use. use that instead of calculating what the maximum we will use is in a couple places. generally makes things easier to understand. * respect a device's request to always use maximum packet size.
* support 24-bit encodings. simplify the way supported encodings arejakemsr2010-07-201-190/+154
| | | | | | | | | | | handled by storing an array of supported encodings. NOTE: this also removes all conversions from this driver. in particular, uaudio no longer supports 16-bit big endian encodings, because the USB audio specification only supports little endian encodings. ok ratchov
* * don't round blocksize to multiples of 16; can cause problems whenjakemsr2010-07-191-5/+2
| | | | | | | | sample size or number of channels is not a power of 2. * use 'param->bps' instead of 'param->precision / NBBY' for the number of bytes per sample. ok ratchov
* add a quirk to allow attaching devices which claim to have a vendorjakemsr2010-07-191-8/+22
| | | | | | | defined interface class, but are audio class compliant enough to be supported by this driver. the E-MU 0202 USB is such a device. this gets it attaching, but needs some forthcoming commits to make it usable.
* move audio specific quirks out of usb_quirks and into uaudiojakemsr2010-07-191-11/+53
| | | | ok krw
* add two new members to structs audio_encoding and audio_prinfo.jakemsr2010-07-151-9/+21
| | | | | | | | | | for both structs, the new members are 'bps' and 'msb', which describe the number of bytes per sample and data alignment in the sample, respectively. drivers must properly set these fields in the 'query_encoding', 'set_parameters' and 'get_default_params' hardware interface methods. discussed with ratchov, deraadt
* calculate the number of frames per usb xfer only once, and take intojakemsr2009-12-041-9/+5
| | | | | | account possible "fractional samples" which occur when the usb frame rate is not a whole number factor of the audio sample rate, such as with 44.1 kHz audio sample rate and full-speed usb (1 kHz frame rate).
* instead of returning a structure, return the only member of thejakemsr2009-12-041-18/+13
| | | | structure that will be used. discussed with deraadt.
* In uaudio_detach(), check that sc->sc_alts is not NULL beforeratchov2009-12-041-1/+7
| | | | | | | | using it. This could happen if uaudio_attach() failed, for instance because the device has no valid audio stream interface. Certain MIDI devices expose such descriptors. ok jakemsr@
* allow USB xfer requests to use up to 16 frames per xfer, depending onjakemsr2009-11-261-24/+67
| | | | blocksize
* greatly reduce latency and kill some XXXs:jakemsr2009-11-261-66/+93
| | | | | | | | | | | | | | * reduce number of outstanding USB xfers: 6 -> 3 * reduce number of USB frames per xfer: 10 -> 2 * if the device uses wMaxPacketSize frame sizes that are longer than 1 ms, allow 1 frame per xfer * instead of making blocksizes big enough to hold all outstanding xfers, just make it big enough to hold one xfer * calculate blocksizes a little better * be more careful to let the upper layer know exactly when a block has been moved in/out of the upper layer buffer ok ratchov
* don't take playback blocksize constraints into account when roundingjakemsr2009-11-031-2/+3
| | | | blocksizes if the device doesn't support playback.
* don't claim to support full-duplex if the device doesn't support bothjakemsr2009-11-031-2/+9
| | | | recording and playback
* provide a get_default_params method. tries aucat(1) defaults firstjakemsr2009-11-031-2/+43
| | | | | | but returns the closest parameters the device supports. ok rathcov
* rewrite supported audio parameter matching codejakemsr2009-11-031-134/+97
| | | | | | | | - easier to read/follow - if can't match desired parameters exactly, find closest match instead of returning an error. this is how most other audio drivers work. ok ratchov
* remove bogus quirk. these devices do not lie about their type, butjakemsr2009-10-171-4/+1
| | | | | | | they do have bSynchAddress set to 0 in their endpoint descriptor. uaudio(4) used to not handle that correctly, but now does. positive response from krw, deraadt, ratchov
* If the bSynchAddress of the AudioStreaming isochronous audio datajakemsr2009-10-151-22/+22
| | | | | endpoint descriptor is set to 0, it means that a synchronization pipe is not needed.