On Sat, May 28, 2011 at 09:48:52AM +0200, Marc Espie wrote:
On Sat, May 28, 2011 at 12:43:29AM +, Jacob Meuser wrote:
more to the point: OpenBSD's audio is a bit less sucky than it used to
be. the people who want to change the way aucat works are not the
people who made audio less
On Thu, May 26, 2011 at 07:23:23AM -0500, Marco Peereboom wrote:
sane defaults. I agree with stu.
the current default is sane. if aucat is quieter by default, then I
suspect there will be *more* complaints that speakers are too quiet.
can we please just accept that a 100% perfect for everyone
On Sat, May 14, 2011 at 07:29:01PM +0300, Sviatoslav Chagaev wrote:
On Mon, 9 May 2011 12:44:54 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
ok then, why do some devices have 'outputs.dac' yet others have
'inputs.dac'? what is the difference to the user? which is more
correct
On Sat, May 14, 2011 at 07:02:21PM +0300, Sviatoslav Chagaev wrote:
I always thought that the idea behind the *ctl programs is to provide a
way to configure totally different things in a similar manner.
Therefore *ctl programs should behave as similarily as possible.
so where is your diff to
On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote:
On Wed, 11 May 2011 03:35:56 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
clipping is better than normalizing? really?
Clipping might describe something like value0xff, so no, not
clipping, saturating addition
clipping is better than normalizing? really?
what about the case where aucat is used for offline mixing?
like the mixerctl change, you are taking away things that exist
for good reason, because it makes *your* situation better in *your*
opinion, when you can (mostly) have what you want with the
On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote:
On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org
wrote:
On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote:
* sorted output looks cleaner, prettier;
* it's easier to find the variable
On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote:
* sorted output looks cleaner, prettier;
* it's easier to find the variable you're looking for in a sorted
output;
* hierarchical variable names yet unordered? doesn't make sense;
* this way mixerctl's behaviour will be
dcoppa@ noticed that his camera still didn't work with ffmpeg after
the latest uvideo changes. the problem was that the device reported
a ridiculously large maximum frame size, and then malloc(9) failed
because there wasn't enough free memory to allocate the frame buffer.
this is similar to a
while working on an update for ffmpeg, I noticed it's ability to
record from a video(4) device is now completely broken because video(4)
doesn't yet support VIDIOC_{S,G}_PARM.
so I added support for the VIDIOC_{S,G}_PARM ioctls to video(4) and
uvideo(4).
but then ffmpeg still couldn't record
I like this *MUCH* better than the way acpithinkpad volume buttons
currently work. these buttons should be affecting the mixer, if
at all possible, instead of doing things behind the audio system's
back, which causes confusion.
On Sun, Mar 13, 2011 at 10:11:54PM +0300, Alexander Polakov wrote:
the following diff make mfi(4) use 64-bit frames, and support 64-bit
dma addresses. these changes are based on freebsd's mfi(4). however,
freebsd only uses 64-bit frames 'if (sizeof(bus_addr_t)) == 8',
whereas this patch uses 64-bit frames unconditionally, for both 32-bit
and 64-bit platforms.
some ATI azalia controllers are brojen after resume, as in PR 6550.
the following diff gathers most of the pci conf register manipulation
done in azalia_pci_attach() into a new function, azalia_configure_pci(),
and calls that function in azalia_pci_attach() and azalia_resume().
this fixes one
On Mon, Feb 28, 2011 at 08:56:57PM -0500, Brad wrote:
On Mon, Feb 28, 2011 at 11:16:49PM +, Jacob Meuser wrote:
some ATI azalia controllers are brojen after resume, as in PR 6550.
the following diff gathers most of the pci conf register manipulation
done in azalia_pci_attach
On Thu, Feb 10, 2011 at 02:21:23AM -0800, Daniel C. Sinclair wrote:
On Wed, Feb 9, 2011 at 10:52 PM, Jacob Meuser jake...@sdf.lonestar.org
wrote:
this actually works? could you please send usbctl (from the usbutil
package) output for this device? I don't like adding more quirks
this actually works? could you please send usbctl (from the usbutil
package) output for this device? I don't like adding more quirks.
if the device has the bulk endpoints in the control interface, then the
requirement that the endpoints be in a different interface is overly
restrictive.
On Wed,
widget connection lists are described as a series of nids. the widget
gives the number of connection list entries. if the most significant
bit of a connection list entry is set, all nids between the last nid
in the connection list and the nid in the entry with the most significant
bit set are
On Fri, Jan 28, 2011 at 09:17:22PM +, Jacob Meuser wrote:
currently, the USB_DEVICEINFO ioctl (used by usbdevs(8)) races against
usb device attach/detach. this is particularly problematic for device
detachment. if the ioctl is running exactly when a hub with devices
attached is removed
currently, the USB_DEVICEINFO ioctl (used by usbdevs(8)) races against
usb device attach/detach. this is particularly problematic for device
detachment. if the ioctl is running exactly when a hub with devices
attached is removed, there's a good chance of crashing.
the following diff makes the
NetBSD (where our usb stack came from) has a /dev/usb device node.
this node exists primarily for reading usb events. however, we
do not create /dev/usb, which means we have no way to get the usb
events. usb events are device/driver attach/detachments. we have
hotplug(4) to get this info.
I
On Sun, Jan 23, 2011 at 05:03:18AM +, Jacob Meuser wrote:
NetBSD (where our usb stack came from) has a /dev/usb device node.
this node exists primarily for reading usb events. however, we
do not create /dev/usb, which means we have no way to get the usb
events. usb events are device
when a USB device is inserted, usbd_probe_and_attach() first tries to
find a driver that claims to support the device by matching the
vendor/product IDs. if no such driver is found, usbd_probe_and_attach()
loops through each interface of each of the devices configurations,
trying to match
there,
so that shouldn't happen.
On 2011/01/04, at 8:18, Jacob Meuser wrote:
when a USB device is inserted, usbd_probe_and_attach() first tries to
find a driver that claims to support the device by matching the
vendor/product IDs. if no such driver is found, usbd_probe_and_attach()
loops
On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
the following diff tries to make sure that no other processes/threads
are or will be using the drivers software context when the driver is
detached.
same treatment for otus(4), rsu(4) and urtwn(4)
ok?
--
jake...@sdf.lonestar.org
no feedback yet. anyone care to comment on this?
On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
the following diff tries to make sure that no other processes/threads
are or will be using the drivers software context when the driver is
detached.
this diff covers rum(4), run(4
On Sat, Dec 18, 2010 at 10:14:54AM +0200, Vladimir Kirillov wrote:
Hello, t...@!
Since a lot of HP usb printers work badly (or do not work at all)
with ulpt and they want all cups and hplip goo, I've added a
new UQ_SHOULD_UGEN quirk to let ulpt(4) know when to skip the device.
I suggested a
On Sat, Dec 18, 2010 at 08:48:10AM +, Jacob Meuser wrote:
On Sat, Dec 18, 2010 at 10:14:54AM +0200, Vladimir Kirillov wrote:
Hello, t...@!
Since a lot of HP usb printers work badly (or do not work at all)
with ulpt and they want all cups and hplip goo, I've added a
new
this adds activate functions for drivers that don't have them. also
add usbd_deactivate() in DVACT_DEACTIVATE for drivers that do have
activate functions but don't have any dying flag.
ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: if_cdcef.c
On Sun, Dec 19, 2010 at 05:02:54AM +0200, Paul Irofti wrote:
On Sat, Dec 18, 2010 at 11:11:35PM +, Jacob Meuser wrote:
this adds activate functions for drivers that don't have them. also
add usbd_deactivate() in DVACT_DEACTIVATE for drivers that do have
activate functions but don't
ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.75
diff -u -p usb_subr.c
--- usb_subr.c 6 Dec 2010
any further thoughts on this?
On Sun, Dec 12, 2010 at 01:02:41PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:56:38PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:35:00PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
Date
On Sat, Dec 11, 2010 at 08:56:38PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:35:00PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
Date: Wed, 8 Dec 2010 06:07:30 +
From: Jacob Meuser jake...@sdf.lonestar.org
I recently
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
Date: Wed, 8 Dec 2010 06:07:30 +
From: Jacob Meuser jake...@sdf.lonestar.org
I recently got a hp officejet 4500. it's a 3-in-1 printer/scanner/fax.
printing works great with the hplip packages. scanning doesn't work
On Sat, Dec 11, 2010 at 08:35:00PM +, Jacob Meuser wrote:
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
Date: Wed, 8 Dec 2010 06:07:30 +
From: Jacob Meuser jake...@sdf.lonestar.org
I recently got a hp officejet 4500. it's a 3-in-1 printer/scanner/fax
I recently got a hp officejet 4500. it's a 3-in-1 printer/scanner/fax.
printing works great with the hplip packages. scanning doesn't work at
all.
I tracked the problem to read() failing in usb_bulk_read() in libusb.
errno was EINTR. so I made this function just continue when read() got
EINTR.
umodem(4) doesn't support devices that don't have a data interface.
this patch moves a chunk of code from the driver's attach function
that iterates over the usb descriptors to find the data endpoint
and other capabilities to a separate function. this function is
then used in the match function,
On Thu, Nov 25, 2010 at 12:45:10PM +, Kevin Chadwick wrote:
On Wed, 24 Nov 2010 20:59:22 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
thoughts?
Probably not the thoughts your after especially on tech, but some of the
panics I was seeing a while back (keep meaning to run more
when a usb device is removed from a port, a hub interrupt is
generated. this causes a hub explore task to be scheduled,
which will find that the device has been removed then detach
the driver via usb_disconnect_port(). so there is some time
between when the device is removed and the driver
On Mon, Nov 22, 2010 at 09:09:17AM -0500, Ted Unangst wrote:
On Mon, Nov 22, 2010 at 12:06 AM, Jacob Meuser jake...@sdf.lonestar.org
wrote:
On Sun, Nov 21, 2010 at 06:47:01PM -0500, Ted Unangst wrote:
instead of faking an assertwaitok check, let's use the real thing. this
is almost
On Sun, Nov 21, 2010 at 06:47:01PM -0500, Ted Unangst wrote:
instead of faking an assertwaitok check, let's use the real thing. this
is almost the opposite of progress on the whole bluetooth issue, but it
shortens the stack trace considerably. the curproc check isn't terribly
accurate,
if a usb device is plugged in, then unplugged before the driver fully
attaches, the driver detach routine might try to release resources that
haven't been allocated. timeout(9)s are one such resource. the
following diff checks if a timeout exists with timeout_initialized()
before doing
like the timeout(9) diff, but for network interfaces. I discussed this
a bit with damien@ when I ran into this with rum(4), and he suggested
testing if_flags. I don't work on network drivers ...
ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index:
On Sat, Oct 23, 2010 at 04:20:12PM +, Jacob Meuser wrote:
like the timeout(9) diff, but for network interfaces. I discussed this
a bit with damien@ when I ran into this with rum(4), and he suggested
testing if_flags. I don't work on network drivers ...
new version after feedback from
when a usb transfer (xfer) is started, the underlying hci driver
adds a timeout that adds a usb task that aborts the xfer.
if an xfer is synchronous, the upper usb layer sleeps waiting for
the xfer to complete. it will also be woken up by the above mentioned
abort task if the xfer times out.
the fidx field of struct uvideo_res is used as the frame index in the
video stream probe/commit commands. this must be the bFrameIndex
value from the frame descriptor, not the index of the frame descriptor
in our software array of frame descriptors. although the uvc spec implies
that the numbers
choose the bAlternateSetting with the closest matching bandwidth,
not the first one we come across that has at least as much as
we need. the bAlternateSettings aren't guaranteed to be ordered
by increasing bandwidth, and using one with too much bandwidth can
stall the usb pipes. lets the Ricoh
On Fri, Oct 15, 2010 at 09:08:01PM +, Jacob Meuser wrote:
choose the bAlternateSetting with the closest matching bandwidth,
not the first one we come across that has at least as much as
we need. the bAlternateSettings aren't guaranteed to be ordered
by increasing bandwidth, and using one
also, there's a bit of extra copying from auich(4). in auich, adj_rate
is the rate after adjusting for the base rate not being 48kHz. there
is not such adjustment in auglx.
I do not have an auglx(4), so testing is appreciated.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System -
I have no auacer(4), testing appreciated.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: auacer.c
===
RCS file: /cvs/src/sys/dev/pci/auacer.c,v
retrieving revision 1.9
diff -u -p auacer.c
I've no autri(4) either.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: autri.c
===
RCS file: /cvs/src/sys/dev/pci/autri.c,v
retrieving revision 1.27
diff -u -p autri.c
--- autri.c 7
On Sat, Aug 21, 2010 at 07:46:12PM -0700, Matthew Dempsky wrote:
On Sun, Aug 22, 2010 at 01:41:54AM +, Jacob Meuser wrote:
this is in the device task loop to catch that:
+ if (!TAILQ_EMPTY(usb_hub_tasks))
+ break
new diff. integrated matthew's comments and task thread
loop and:
* put the hub explore task on the task queue, don't run it
directly (except in usb_attach()). add comments about why.
* make sure high speed hubs explore before companion low/
full speed hubs
* handle config_pending_{inrc,decr}
usb(4) has a per-instance event thread, and there is also
a single task thread that runs all other usb_tasks.
usb_tasks are added to a tailq and the task thread runs
the tasks one at a time.
the per-usb event threads only run root hub explorations.
these are responsible for determining when a
On Sat, Aug 21, 2010 at 04:31:58PM -0700, Matthew Dempsky wrote:
On Sat, Aug 21, 2010 at 08:25:23AM +, Jacob Meuser wrote:
+volatile int usb_run_tasks;
+volatile int discover_pending = 0;
Do these really need to be volatile?
no
+/* called by usbd_finish when lasst usb is detached
On Fri, Jul 30, 2010 at 09:20:30PM +0100, Jason McIntyre wrote:
On Fri, Jul 30, 2010 at 09:48:43PM +0200, Mark Kettenis wrote:
Date: Fri, 30 Jul 2010 20:33:23 +0100
From: Jason McIntyre j...@kerhand.co.uk
On Thu, Jul 29, 2010 at 03:22:12PM +0100, Jason McIntyre wrote:
On Tue, Jul
On Fri, Jul 30, 2010 at 08:37:05PM -0400, Daniel Dickman wrote:
Sorry, I don't think this makes sense. I always start with doing a
make obj. It's way too easy to mess things things up if you forget to
do that step, so running anything in my source tree without doing make
obj first makes
On Sun, Jul 04, 2010 at 01:23:14PM +0200, Denis Fondras wrote:
Hello all,
I have a Roland UA-25EX audio interface (USB) and I'm trying to make
it work with OpenBSD.
I added the VID/PID (0582/00E6) to usbdevs, usbdevs.h and
usbdevs_data.h so the device is detected. After kernel compilation
On Sun, Jun 13, 2010 at 08:58:17AM +, Jacob Meuser wrote:
I haven't gotten any test results on this yet
it will be committed in the next day or so, so test and/or speak up
now if you care.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
ym(4) needs the following in addition.
I haven't gotten any test results on this yet ... a lot of the
code in audioce(4) and audiocs(4) in sparc64 and sparc come from
here ... the plan is to split the MI code out and share instead
of having it copied in several places. so, this is not just for
audio(9) has two different methods for managing DMA transfers. the
original method is essentially a callback that gives the low level
driver the current kernel audio buffer position and block size
when each block is to be moved. the newer (well, at least 12 yrs
old) method just gives the low
On Fri, Apr 02, 2010 at 06:57:54PM -0700, J.C. Roberts wrote:
On Fri, 2 Apr 2010 22:45:12 +0200 Alexandre Ratchov a...@caoua.org
wrote:
A short summary of the changes:
- According to specification AUICH_RR may only be set after DMA
is halted (AUICH_DCH is 0 in AUICH_STS). To
On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote:
On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote:
are you talking about Bret's reply about buzzwords? imo, that's what
that reply was about, buzzwords. there was nothing personal. see,
the way buzzwords work
On Tue, Feb 02, 2010 at 11:58:37AM -0700, Darrin Chandler wrote:
On Tue, Feb 02, 2010 at 06:36:14PM +, Jacob Meuser wrote:
On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote:
On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote:
are you talking about Bret's reply
On Mon, Feb 01, 2010 at 03:28:22PM -0700, Darrin Chandler wrote:
On Mon, Feb 01, 2010 at 03:05:37PM -0700, Nick Bender wrote:
On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck b...@ualberta.ca wrote:
On 1 February 2010 14:09, Donald Allen donaldcal...@gmail.com wrote:
I have not responded to this
On Tue, Dec 15, 2009 at 09:02:19PM -0500, Brad Tilley wrote:
# cvs diff -Nup sys/arch/vax/qbus/uda.c
Index: sys/arch/vax/qbus/uda.c
===
RCS file: /cvs/src/sys/arch/vax/qbus/uda.c,v
retrieving revision 1.6
diff -N -u -p
On Fri, Nov 20, 2009 at 03:45:31PM +0100, Peter Hessler wrote:
mixerctl inputs.master=[0,255]
record.volume, actually. historical/consistency reasons.
mixerctl outputs.master=[0,255]
those two should do what you want. the rest are there for people that
like to poke at their audio bits.
On Fri, Nov 20, 2009 at 08:16:40PM +0100, Atle Kristensen wrote:
what about audioctl, I think that the defaults could be more sane on USB
audio's?
(OpenBSD 4.6
play.rate=32000
play.channels=1
play.precision=8
this was recently changed in -current to try to set 44.1 kHz stereo 16-bit
On Fri, Nov 20, 2009 at 08:28:34AM -0800, Ted Unangst wrote:
On Nov 20, 2009, at 8:03 AM, Thomas Pfaff tpf...@tp76.info wrote:
On Fri, 20 Nov 2009 15:45:31 +0100
Peter Hessler phess...@theapt.org wrote:
mixerctl inputs.master=[0,255]
mixerctl outputs.master=[0,255]
Still, is a simpler
no comments?
On Fri, Oct 23, 2009 at 01:16:18AM +, Jacob Meuser wrote:
this diff encodes the audio stream channel numbers converters will
process into converter mixer names.
e.g.
inputs.dac - inputs.dac-0:1
inputs.dac2 - inputs.dac-2:3
inputs.dac3 - inputs.dac-4:5
pros
On Thu, Oct 22, 2009 at 11:02:37PM +0200, Pawlowski Marcin Piotr wrote:
On Thu, 22 Oct 2009 22:33:23 +0200
Pawlowski Marcin Piotr pawlowski...@gmail.com wrote:
Hi,
I was playing with audioctl and found that:
- fullduplex and full_duplex are the same so one of them is redundant
so? did
On Fri, Oct 23, 2009 at 12:55:39AM +0200, Pawlowski Marcin Piotr wrote:
On Thu, 22 Oct 2009 21:41:45 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
On Thu, Oct 22, 2009 at 11:02:37PM +0200, Pawlowski Marcin Piotr
wrote:
On Thu, 22 Oct 2009 22:33:23 +0200
Pawlowski Marcin Piotr
this diff encodes the audio stream channel numbers converters will
process into converter mixer names.
e.g.
inputs.dac - inputs.dac-0:1
inputs.dac2 - inputs.dac-2:3
inputs.dac3 - inputs.dac-4:5
pros:
* easier to understand what channels are going where
* very similar in format to aucat channel
relevant part of original NetBSD commit message which added this:
UQ_AU_INP_ASYNC for input devices that claim to be adaptive, but are
in fact asynchronous (an easy mistake to make unless you read the
specs carefully :)
the specs say no such thing.
the specs say:
a) input adaptive
maybe you've seen such a line in your dmesg after plugging in USB
audio devices:
uaudio0: ignored input endpoint of type adaptive
or
uaudio0: ignored output endpoint of type async
these input/adaptive and output/async endpoints need external help to
synchronize them, or more accurately, to keep
On Thu, Jun 25, 2009 at 05:07:58PM +0100, Edd Barrett wrote:
Hi,
On Sat, Jun 20, 2009 at 1:57 AM, Jacob Meuserjake...@sdf.lonestar.org wrote:
Any clues what may be wrong here? I am willing to have a look at the
code myself if no-one has any ideas.
please do ;) ?the mixer interface in
On Sun, Jun 28, 2009 at 07:35:07PM +0100, Edd Barrett wrote:
Hi Jacob,
On Sun, Jun 28, 2009 at 04:50:41PM +, Jacob Meuser wrote:
the audio codec is the same. the bus architecture differs. cs4231(4)
uses sbus while ce4231(4) uses ebus.
I can't send a diff, as my disk died
only 4 people have ati or nvidia azalia(4)?
On Tue, Jun 23, 2009 at 01:42:49AM +, Jacob Meuser wrote:
On Sun, Jun 21, 2009 at 01:07:37AM +, Jacob Meuser wrote:
On Mon, Feb 09, 2009 at 12:40:31AM +, Owain Ainsworth wrote:
On Sun, Feb 08, 2009 at 05:11:16PM -0500, Brad wrote
On Mon, Feb 09, 2009 at 12:40:31AM +, Owain Ainsworth wrote:
On Sun, Feb 08, 2009 at 05:11:16PM -0500, Brad wrote:
Please test the following diff with any azalia(4) adapter, but especially
with any ATI or NVIDIA chipsets. Make sure sound still works properly
without any unusual sound
the idea is that when a codec is capable of playing at least 6
channels, the output jacks should be connected to unique DACs
by default. it's not possible to do multichannel playback if
all the output jacks are connected to the same DAC.
it is also common for multichannel capable codecs to have
79 matches
Mail list logo
