| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
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@
|
|
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.
ok tedu@ deraadt@
|
|
|
|
ok tedu@ deraadt@
|
|
ok deraadt@ tedu@
|
|
ok miod@
|
|
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.
|
|
after discussions with beck deraadt kettenis.
|
|
is not part of the address. From Remco <remco at d-compu.dyndns.org>,
thanks!
ok mpi@
|
|
|
|
Okay mpi@
|
|
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
|
|
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@
|
|
|
|
absolutely do not need to include vnode.h because it includes uvm_extern.h
and you want the idiotic TRUE FALSE defines from uvm.
|
|
devices using sych endpoints. From Gregor Pintar <grpintar at gmail.com>
Thanks!
|
|
ok deraadt@/dcoppa@ and sthen@.
|
|
|
|
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@
|
|
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
|
|
them from userland, and nothing in the kernel uses them.
ok krw@, miod@
|
|
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
|
|
* use the correct variable in a DPRINTF
|
|
complete outstanding requests, so use uaudio_drain in uaudio_detach.
* the channel alt index can still be -1 at detach. check for this.
|
|
device configuration descriptor in the match() function. stops
midi devices from attaching as uaudio then bailing out, leaving
a phantom uaudio.
|
|
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?
|
|
presumably from a missing commit to a header file. go ahead kettenis@ todd@
|
|
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?
|
|
* 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.
|
|
ridiculous value.
* encoding expansion factor is always 1.
|
|
only function that was using it.
|
|
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.
|
|
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.
|
|
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
|
|
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
|
|
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.
|
|
ok krw
|
|
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
|
|
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).
|
|
structure that will be used. discussed with deraadt.
|
|
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@
|
|
blocksize
|
|
* 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
|
|
blocksizes if the device doesn't support playback.
|
|
recording and playback
|
|
but returns the closest parameters the device supports.
ok rathcov
|
|
- 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
|
|
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
|
|
endpoint descriptor is set to 0, it means that a synchronization
pipe is not needed.
|
