On Sat, May 28, 2011 at 09:48:52AM +0200, Marc Espie wrote:
> On Sat, May 28, 2011 at 12:43:29AM +0000, 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
>
On Fri, May 27, 2011 at 09:53:53PM +0200, Marc Espie wrote:
> On Fri, May 27, 2011 at 07:01:28AM +0000, Jacob Meuser wrote:
> > can we please just accept that a "100% perfect for everyone" solution
> > is not really possible?
>
> Of course not, that way lies medio
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 everyon
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 t
On Sat, May 14, 2011 at 07:29:01PM +0300, Sviatoslav Chagaev wrote:
> On Mon, 9 May 2011 12:44:54 +
> Jacob Meuser wrote:
> > ok then, why do some devices have 'outputs.dac' yet others have
> > 'inputs.dac'? what is the difference to the user? which
On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote:
> On Wed, 11 May 2011 03:35:56 +
> Jacob Meuser wrote:
>
> > clipping is better than normalizing? really?
>
> Clipping might describe something like value&0xff, so no, not
> clipping, satu
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
> wrote:
> > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote:
> >> * sorted output looks cleaner, prettier;
> >> * it's easier
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 c
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 pro
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 from
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. I
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:
On Mon, Feb 28, 2011 at 08:56:57PM -0500, Brad wrote:
> On Mon, Feb 28, 2011 at 11:16:49PM +0000, 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
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 repo
at line 190, if nports == 0, 'hub' will be NULL at line 334, and
'if (hub->ports)' will be a NULL dereference.
found by Amit Kulkarni using clang.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: uhub.c
==
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
> wrote:
> > this actually works? could you please send usbctl (from the usbutil
> > package) output for this device? I don't like adding more quirks.
&g
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,
On Tue, Feb 08, 2011 at 04:08:53AM +, Jacob Meuser wrote:
> 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 th
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 con
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
>
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 ra
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 event
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 don
se of a ugen attached to a umass interface that is
controlling a filesystem, for example. but we attach umass 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
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 "interfa
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?
On Thu, Dec 23, 2010 at 01:30:15PM +0100, Thomas Pfaff wrote:
> On Thu, 23 Dec 2010 00:36:26 +
> Jacob Meuser wrote:
>
> > no feedback yet. anyone care to comment on this?
> >
> > > this diff covers rum(4), run(4), ural(4) and urtw(4). without the
> > &
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 di
On Sun, Dec 19, 2010 at 05:02:54AM +0200, Paul Irofti wrote:
> On Sat, Dec 18, 2010 at 11:11:35PM +0000, 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
> &
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 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 hpli
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 suggest
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
> Sorry, but this very much feels like you're hacking around a bug in
> the application you're using. If it installs signal handler without
> specifying the SA_RESTART flag, it has to deal with read(2) failing
> with EINTR.
after tal
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), ural(4) and urtw(4). without the
diff, I can get the kernel to crash by starting a scan with
the deice, then ejecti
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 04:3
this make *hci use the dying flag in struct usbd_bus instead of one in
their own softc. struct usbd_bus is required to be the first member of
*hci_softc.
the bus' dying flag is checked in usbd_is_dying(), which is used to
let the usb stack know if the hardware is a usable.
ok?
--
jake...@sdf.l
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 +0000, Jacob Meuser wrote:
> > On Sat, Dec 11, 2010 at 08:35:00PM +0000, Jacob Meuser wrote:
> > > On Sat, Dec 11, 2010 at 08:14:24PM +0100, M
On Sat, Dec 11, 2010 at 08:56:38PM +, Jacob Meuser wrote:
> On Sat, Dec 11, 2010 at 08:35:00PM +0000, Jacob Meuser wrote:
> > On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
> > > > Date: Wed, 8 Dec 2010 06:07:30 +0000
> > > > From: Jacob Meuser
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
> > >
> > > I recently got a hp officejet 4500. it's
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
> > Date: Wed, 8 Dec 2010 06:07:30 +
> > From: Jacob Meuser
> >
> > I recently got a hp officejet 4500. it's a 3-in-1 printer/scanner/fax.
> > printing works great with the hplip packages
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, a
On Thu, Nov 25, 2010 at 12:45:10PM +, Kevin Chadwick wrote:
> On Wed, 24 Nov 2010 20:59:22 +
> Jacob Meuser wrote:
>
> > thoughts?
>
> Probably not the thoughts your after especially on tech, but some of the
> panics I was seeing a while back (keep meanin
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 detach
On Mon, Nov 22, 2010 at 09:09:17AM -0500, Ted Unangst wrote:
> On Mon, Nov 22, 2010 at 12:06 AM, Jacob Meuser
> 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
>
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,
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
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: if_
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 timeout_de
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.
but
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 ban
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 VG
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
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 S
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
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 - http://
two things here. I have no auixp so testing is appreciated.
first, suspend/resume support using audio(4)'s DVACT_{QUIESCE,RESUME}.
second, this driver will only ever support one audio I/O codec, so:
a) don't keep an array of descriptions for all codecs.
b) use the first codec that we can attach,
sys/videoio.h defines anonymous unions. these aren't standard C, and
gcc-<3 does not support them.
this diff simply names the anonymous unions 'un'.
there is also a diff for the 4 ports affected by this change. video(1)
can presumably be re-enabled in xenocara and removed from ports.
while her
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} co
On Sat, Aug 21, 2010 at 07:46:12PM -0700, Matthew Dempsky wrote:
> On Sun, Aug 22, 2010 at 01:41:54AM +0000, Jacob Meuser wrote:
> > this is in the device task loop to catch that:
> >
> > > > + if (
On Sat, Aug 21, 2010 at 04:31:58PM -0700, Matthew Dempsky wrote:
> On Sat, Aug 21, 2010 at 08:25:23AM +0000, Jacob Meuser wrote:
> > +volatile int usb_run_tasks;
> > +volatile int discover_pending = 0;
>
> Do these really need to be volatile?
no
> +/* called by usbd_
On Sat, Aug 21, 2010 at 10:46:22AM -0400, Kenneth R Westerback wrote:
> On Sat, Aug 21, 2010 at 07:43:18AM +0000, Jacob Meuser wrote:
> > returning here without calling usb_transfer_complete() can cause
> > the usbtask thread to sleep forever, which breaks all usb devices
> &g
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
returning here without calling usb_transfer_complete() can cause
the usbtask thread to sleep forever, which breaks all usb devices
that use usb_tasks.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: ehci.c
===
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
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
> > >
> > > On Thu, Jul 29, 2010 at 03:22:12PM +0100, Jason McIntyre wrote:
> > > > On Tue, Jul 2
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 compi
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
th
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 leve
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
> 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 ac
On Thu, Mar 11, 2010 at 12:11:42PM +0100, David Coppa wrote:
> Hi,
>
> The following diff makes auich.c not print ac97 link rate messages unless
> AUICH_DEBUG is enabled. This is to prevent kernel from yelling at me
> during boot when aucat is started:
>
> ...
> preserving editor files.
> starti
On Tue, Feb 02, 2010 at 11:58:37AM -0700, Darrin Chandler wrote:
> On Tue, Feb 02, 2010 at 06:36:14PM +0000, 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:
> > &
On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote:
> On Tue, Feb 02, 2010 at 02:51:52AM +0000, 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. s
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 wrote:
> > > On 1 February 2010 14:09, Donald Allen wrote:
> > >> I have not responded to this thread because I was angered
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 sys/
On Sat, Nov 21, 2009 at 12:28:38AM -0500, Ted Unangst wrote:
> On Fri, Nov 20, 2009 at 3:19 PM, Jacob Meuser
> wrote:
> >> If you don't like mixerctl, there's at least a half dozen mixers in
> >> ports.
> >
> > those don't help at all. cmi
On Fri, Nov 20, 2009 at 05:47:19PM +0100, Thomas Pfaff wrote:
> On Fri, 20 Nov 2009 08:28:34 -0800
> Ted Unangst wrote:
>
> > On Nov 20, 2009, at 8:03 AM, Thomas Pfaff wrote:
> >
> > > On Fri, 20 Nov 2009 15:45:31 +0100
> > > Peter Hessler wrote:
> > >
> > >> mixerctl inputs.master=[0,255]
> >
On Fri, Nov 20, 2009 at 08:28:34AM -0800, Ted Unangst wrote:
> On Nov 20, 2009, at 8:03 AM, Thomas Pfaff wrote:
>
> >On Fri, 20 Nov 2009 15:45:31 +0100
> >Peter Hessler wrote:
> >
> >>mixerctl inputs.master=[0,255]
> >>mixerctl outputs.master=[0,255]
> >
> >Still, is a simpler sysctl interface s
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-b
On Fri, Nov 20, 2009 at 04:10:26PM +0100, Thomas Pfaff wrote:
> On Fri, 20 Nov 2009 15:45:31 +0100
> Peter Hessler wrote:
>
> > mixerctl inputs.master=[0,255]
> > mixerctl outputs.master=[0,255]
> >
> >
> > those two should do what you want. the rest are there for people that
> > like to poke
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 bit
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
>
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 chann
On Fri, Oct 23, 2009 at 12:55:39AM +0200, Pawlowski Marcin Piotr wrote:
> On Thu, 22 Oct 2009 21:41:45 +
> Jacob Meuser wrote:
>
> > On Thu, Oct 22, 2009 at 11:02:37PM +0200, Pawlowski Marcin Piotr
> > wrote:
> > > On Thu, 22 Oct 2009 22:33:23 +0200
>
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 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 you consider t
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 endp
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, Oct 01, 2009 at 09:41:53PM -0400, Brad wrote:
> The following diff adds support for the ATI SB600 chipsets AC'97
> controller to the auixp(4) driver.
do vendors actually put audio codecs on those?
what happens if there is no codec?
>
> Index: auixp.c
> ==
the following patch set a couple more bits in the pci configuration
space on nvidia hdaudio controllers. this is what ALSA and OSS are
doing on these devices.
please try this on all nvidia based azalia devices. check that
playback is correct. please include a dmesg with your report. tia.
--
On Sun, Jun 28, 2009 at 07:35:07PM +0100, Edd Barrett wrote:
> Hi Jacob,
>
> On Sun, Jun 28, 2009 at 04:50:41PM +0000, Jacob Meuser wrote:
> > the audio codec is the same. the bus architecture differs. cs4231(4)
> > uses sbus while ce4231(4) uses ebus.
>
> I can
On Thu, Jun 25, 2009 at 05:07:58PM +0100, Edd Barrett wrote:
> Hi,
>
> On Sat, Jun 20, 2009 at 1:57 AM, Jacob Meuser 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
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 +0000, Jacob Meuser wrote:
> > On Mon, Feb 09, 2009 at 12:40:31AM +, Owain Ainsworth wrote:
> > > On Sun, Feb 08, 2009 at 05:11:16PM
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:
> > > Please test the following diff with any azalia(4) adapter, but especially
> >
On Sun, Jun 21, 2009 at 05:22:23AM +, Jacob Meuser wrote:
> On Sat, Jun 20, 2009 at 11:58:52PM +0000, Jacob Meuser wrote:
> > On Sat, Jun 20, 2009 at 11:18:44AM +0000, Jacob Meuser wrote:
> > > for codecs with multiple line out jacks, this patch would use the
> > > c
On Sat, Jun 20, 2009 at 11:58:52PM +, Jacob Meuser wrote:
> On Sat, Jun 20, 2009 at 11:18:44AM +0000, Jacob Meuser wrote:
> > for codecs with multiple line out jacks, this patch would use the
> > color of the jack (according to the codec) in the name instead
> > of enum
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 so
On Sat, Jun 20, 2009 at 11:18:44AM +, Jacob Meuser wrote:
> for codecs with multiple line out jacks, this patch would use the
> color of the jack (according to the codec) in the name instead
> of enumerating the jacks, if all the line out jack have different
> colors.
for codecs with multiple line out jacks, this patch would use the
color of the jack (according to the codec) in the name instead
of enumerating the jacks, if all the line out jack have different
colors. for example:
outputs.line-> outputs.line-grn
outputs.line2 -> outputs.line-org
outputs.l
1 - 100 of 106 matches
Mail list logo
