subject:"uaudio"

Re: Gstreamer-1.0, uaudio(4) and sndio(7) with raw devices.

2017-03-01 Thread percy piper

Apologies for the awful formatting gmail inflicted on my previous mail...

Gstreamer info and dmesg below.


gstreamer1-1.10.4   framework for streaming media
gstreamer1-plugins-base-1.10.4 base elements for GStreamer


>> OpenBSD/amd64 BOOT 3.33
boot>
booting hd0a:/bsd: 6994272+2216968+259456+0+671744
[72+715320+482486]=0xad29b8
entry point at 0x1001000 [7205c766, 3404, 24448b12, 61c0a304]
[ using 1198520 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.0-current (GENERIC) #201: Tue Feb 28 09:52:10 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1707544576 (1628MB)
avail mem = 1651257344 (1574MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9860 (49 entries)
bios0: vendor American Megatrends Inc. version "4.6.4" date 07/18/2012
bios0: AMD Corporation Inagua CRB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) P0PC(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4)
USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) GEC_(S4)
PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40R Processor, 1000.16 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: TSC frequency 1000158860 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (P0PC)
acpiprt2 at acpi0: bus -1 (PE20)
acpiprt3 at acpi0: bus -1 (PE21)
acpiprt4 at acpi0: bus -1 (PE22)
acpiprt5 at acpi0: bus -1 (PE23)
acpiprt6 at acpi0: bus -1 (PCE7)
acpiprt7 at acpi0: bus -1 (PCE8)
acpiprt8 at acpi0: bus 1 (BR14)
acpiprt9 at acpi0: bus -1 (PCE6)
acpicpu0 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6250" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci0 dev 1 function 1 "ATI Radeon HD 6310 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:60:e0:54:31:4d
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19,
AHCI 1.2
ahci0: port 0: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed naa.5000cca5b5ddc5b3
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00
addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00
addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-8500 SO-DIMM
azalia1 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x40: apic 2 int
16
azalia1: codecs: Realtek ALC662
audio0 at azalia1
pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40
ppb1 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
pci2 at ppb1 bus 2
ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ohci3 at pci0 dev 22 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb2 at ehci2: USB revision 2.0
uhub2 at usb2 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00
addr 1
pchb1 at pci0

Gstreamer-1.0, uaudio(4) and sndio(7) with raw devices.

2017-03-01 Thread percy piper

It appears that Gstreamer-1.0 can't access raw uaudio(4) devices (rsnd/n).
I'm struggling to debug further so wanted to ask if this is expected to
work or a known limitation of OpenBSD's sndio(7) implementation for
gstreamer?



This is where I've got to so far:


Gstreamer-1.0 works fine with uaudio(4) devices exposed by sndiod(8) (e.g.
snd/n) but fails with the raw (rsnd/n) device. Once gstreamer has attempted
to use the raw device, the uaudio(4) device is left in an unuseable state
until it is hard reset (unplug / replug).


I've tested several uaudio(4) USB-2 class-compliant devices (Focusrite,
Tascam, M-Audio) on different amd64 -current hosts and the problem appears
to be reproducible on all of them. So it looks like a
gstreamer+sndio+uaudio specific issue?


A simple test to demonstrate would be:

Terminate any running sndiod(8).

env AUDIODEVICE=rsnd/1 gst-launch-1.0 -v sndiosrc ! fakesink
--gst-debug=sndio:9


0:00:00.103475000 21585 0x37af4e42210 LOG sndio gstsndio.c:77:GstCaps
*gst_sndio_getcaps(struct gstsndio *, GstCaps *): getcaps
called, returning template caps

0:00:00.103918000 21585 0x37af4e42210 LOG sndio gstsndio.c:77:GstCaps
*gst_sndio_getcaps(struct gstsndio *, GstCaps *): getcaps
called, returning template caps

Setting pipeline to PAUSED ...

0:00:00.105188000 21585 0x37af4e42210 DEBUG sndio gstsndio.c:111:gboolean
gst_sndio_open(struct gstsndio *, gint): open

0:00:00.10558 21585 0x37af4e42210 WARN sndio gstsndio.c:123:gboolean
gst_sndio_open(struct gstsndio *, gint):0x37b29982c00 error: Couldn't get
device capabilities


(gst-launch-1.0:21585): GStreamer-CRITICAL **:
gst_element_message_full_with_details: assertion 'GST_IS_ELEMENT (element)'
failed

ERROR: Pipeline doesn't want to pause.

Setting pipeline to NULL ...

Freeing pipeline ...


Now, nothing but a hard reset will get the uaudio device working correctly
again. Any further attempts to access the uaudio(4) device returns a
'failed to open device' error. (examples below with both gstreamer and
sndiod)


Other, non gstreamer-1.0 code seems to be unaffected e.g. Audacity will
happily open and use the raw (rsnd/n) device without any apparent error.


The gstreamer code is a bit odd as sndio(7) support is 'patched in' by the
OpenBSD port's Makefile. It fails at gst_sndio_open->sio_getcap in
gstsndio.c:


gboolean

gst_sndio_open (struct gstsndio *sio, gint mode)

{

GValue list = G_VALUE_INIT, item = G_VALUE_INIT;

GstStructure *s;

GstCaps *caps;

struct sio_enc *enc;

struct sio_cap cap;

char fmt[16];

int i, chan;


GST_DEBUG_OBJECT (sio->obj, "open");

sio->hdl = sio_open (sio->device, mode, 0);

if (sio->hdl == NULL) {

GST_ELEMENT_ERROR (sio->obj, RESOURCE, OPEN_READ_WRITE,

("Couldn't open sndio device"), (NULL));

return FALSE;

}

sio->mode = mode;


if (!sio_getcap(sio->hdl, )) {/* Fails here */

GST_ELEMENT_ERROR (sio, RESOURCE, OPEN_WRITE,

("Couldn't get device capabilities"), (NULL));

sio_close(sio->hdl);

sio->hdl = NULL;

return FALSE;

}



All further attempts to open the audio(4) device fail, with either
gstreamer or sndiod(8):


env AUDIODEVICE=rsnd/1 gst-launch-1.0 -v sndiosrc ! fakesink
--gst-debug=sndio:9

0:00:00.100955000 86224 0x122e996b8810 LOG sndio gstsndio.c:77:GstCaps
*gst_sndio_getcaps(struct gstsndio *, GstCaps *): getcaps
called, returning template caps

0:00:00.10116 86224 0x122e996b8810 LOG sndio gstsndio.c:77:GstCaps
*gst_sndio_getcaps(struct gstsndio *, GstCaps *): getcaps
called, returning template caps

Setting pipeline to PAUSED ...

0:00:00.101781000 86224 0x122e996b8810 DEBUG sndio gstsndio.c:111:gboolean
gst_sndio_open(struct gstsndio *, gint): open

0:00:00.103892000 86224 0x122e996b8810 WARN sndio gstsndio.c:116:gboolean
gst_sndio_open(struct gstsndio *, gint): error: Couldn't open
sndio device

ERROR: Pipeline doesn't want to pause.

ERROR: from element /GstPipeline:pipeline0/GstSndioSrc:sndiosrc0: Couldn't
open sndio device

Additional debug info:

gstsndio.c(116): gboolean gst_sndio_open(struct gstsndio *, gint) ():
/GstPipeline:pipeline0/GstSndioSrc:sndiosrc0

Setting pipeline to NULL ...

Freeing pipeline ...


# sndiod -ddd -f rsnd/1

snd0 pst=cfg.default: rec=0:1 dup

helper(helper|ini): created

worker(worker|ini): created

listen(/tmp/aucat/aucat0|ini): created

sock(sock|ini): created

sock,rmsg,widl: AUTH message

sock,rmsg,widl: HELLO message

sock,rmsg,widl: hello from , mode = 2, ver 7

sock,rmsg,widl: using snd0 pst=cfg.default, mode = 2

gstlaun0: overwritten slot 0

snd0 pst=cfg: device requested

worker: send: cmd = 0, num = 0, mode = 2, fd = -1

worker: recv: cmd = 3, num = 0, mode = 0, fd = -1

snd0 pst=cfg: rsnd/1: failed to open audio device

sock,rmsg,widl: closing

sock(sock|zom): destroyed

helper: recv: cmd = 0, num = 0, mode = 2, fd = -1

helper: send: cmd = 3, num = 0, mode = 0, fd = -1

^Cworker(worker|zom): destroyed

listen(/tmp/aucat/aucat0|zom): destroyed

snd0 pst=cfg

Re: uaudio useless?

2014-05-21 Thread Alexandre Ratchov

On Sat, May 17, 2014 at 05:41:06PM +, Christian Weisgerber wrote:
 I just tried to hang a USB audio dongle off my spiffy new machine,
 and was rudely reminded of this long-standing issue:
 
   ehci0: Error opening low/full speed isoc endpoint.
   A low/full speed device is attached to a USB2 hub, and transaction
   translations are not yet supported.
 
 Right.  I had seen this before but forgotten about it, and the
 previous box where I had successfully tested this uaudio device
 happened to be my Sun Blade 100, which only has USB1.1 to begin
 with.
 
 So it seems it is currently impossible to run any uaudio(4) device
 that only supports USB1 speeds on a machine with USB2 ports.  Maybe
 there are audio dongles that run at hi-speed, otherwise uaudio(4)
 looks pretty useless.

exactly, on modern machines. As long as we lack the necessary
support for usb2 hubs (isoc endpoints behind hubs, more precisely).

certain usb hosts don't use hubs or can work as uhci (by disabling
echi), in which case uaudio works. Others use rate matching hubs,
on which uaudio can't work yet.

-- Alexandre

Re: uaudio useless?

2014-05-21 Thread Christian Weisgerber

On 2014-05-21, Alexandre Ratchov a...@caoua.org wrote:

 certain usb hosts don't use hubs or can work as uhci (by disabling
 echi), in which case uaudio works. Others use rate matching hubs,
 on which uaudio can't work yet.

I disabled ehci by way of boot -c

Intel 8 Series USB rev 0x04 at pci0 dev 29 function 0 not configured

but with this there are no USB buses at all.  No hidden uhci.


(I'm documenting this here for general benefit.  I have no urgent
need for uaudio on that machine; if push comes to shove, the analog
outputs of the built-in azalia will do just fine.)

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: uaudio useless?

2014-05-20 Thread Christian Weisgerber

On 2014-05-19, Mike Larkin mlar...@azathoth.net wrote:

 FWIW, I have 3 different uaudio dongles and they all work fine.

It depends on the layout of your USB bus, see usbdevs -v.

On older systems with USB2, full speed devices will be attached
directly to a full speed root hub and the audio dongle will work.
Here's an example from a Thinkpad X40:

---
Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 addr 2: full speed, power 20 mA, config 1, USB Audio DAC(0x2704), 
Burr-Brown from TI(0x08bb), rev 1.00
 port 2 powered
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 powered
 port 2 powered
---

On systems with newer Intel chipsets that support USB3, full speed
devices will be attached to a high speed rate-matching hub and the
audio dongle will not work.  I first noticed this on the Thinkpad
X230 but mostly forgot about it.  Here's an example from a PowerEdge
T20:

---
Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x8008), 
Intel(0x8087), rev 0.04
  port 1 addr 3: low speed, power 100 mA, config 1, product 0x1203(0x1203), 
Holtek(0x04d9), rev 2.70
  port 2 addr 4: low speed, power 100 mA, config 1, TEMPer sensor(0x660c), Ten 
X Technology, Inc.(0x1130), rev 1.50
  port 3 addr 5: full speed, power 20 mA, config 1, USB Audio DAC(0x2704), 
Burr-Brown from TI(0x08bb), rev 1.00
  port 4 powered
  port 5 powered
  port 6 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x8086), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x8000), 
Intel(0x8087), rev 0.04
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
  port 5 powered
  port 6 powered
  port 7 powered
  port 8 powered
 port 2 powered
 port 3 powered
---

Yes, I tried all ten USB ports on that machine.  They're all routed
to one of the rate-matching hubs.

A potential workaround would be to plug a USB2 expansion card into
the box, depending on what the bus layout will be there.  I might
try that, but at the moment the single PCI slot is already occupied.

There should also be high speed USB audio devices, and possibly
asynchronous ones, but this kind of information is difficult to
discern from the packaging or the manual leaflets.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: uaudio useless?

2014-05-19 Thread Mike Larkin

On Sun, May 18, 2014 at 10:17:41PM +0100, Kevin Chadwick wrote:
 previously on this list Christian Weisgerber contributed:
 
  Maybe
  there are audio dongles that run at hi-speed, otherwise uaudio(4)
  looks pretty useless.
 

FWIW, I have 3 different uaudio dongles and they all work fine.
One is a Creative (I can get the model # if you want) and the
other two are no-name brands.

I have a fourth uaudio that attaches in an expresscard slot and that one
doesn't work, but it's not for the same reason as yours (it can't
understand the codecs, I think).

-ml

 I may have one as it supports DSD however it comes up as ugen currently
 so I am not sure if it would use uaudio until I have the time to look
 into how much I can get to work with OpenBSD.
 
 -- 
 ___
 
 'Write programs that do one thing and do it well. Write programs to work
 together. Write programs to handle text streams, because that is a
 universal interface'
 
 (Doug McIlroy)
 
 In Other Words - Don't design like polkit or systemd
 ___
 
 I have no idea why RTFM is used so aggressively on LINUX mailing lists
 because whilst 'apropos' is traditionally the most powerful command on
 Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
 to help psychopaths learn to control their anger.
 
 (Kevin Chadwick)
 
 ___

Re: uaudio useless?

2014-05-19 Thread Christian Weisgerber

On 2014-05-19, Mike Larkin mlar...@azathoth.net wrote:

  Maybe there are audio dongles that run at hi-speed, otherwise uaudio(4)
  looks pretty useless.

 FWIW, I have 3 different uaudio dongles and they all work fine.

Well, these three don't (on USB2.0 ports):

=== HA Info NG Coax 2011
uaudio0 at uhub2 port 4 configuration 1 interface 0 Burr-Brown from TI USB 
Audio DAC rev 1.10/1.00 addr 5
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0
uhidev4 at uhub2 port 4 configuration 1 interface 2 Burr-Brown from TI USB 
Audio DAC rev 1.10/1.00 addr 5
uhidev4: iclass 3/0
uhid2 at uhidev4: input=1, output=0, feature=0

=== HA Info U2 USB to SPDIF
uhidev4 at uhub2 port 4 configuration 1 interface 0 HA INFO HA INFO U2 USB TO 
SPDIF rev 1.10/0.01 addr 5
uhidev4: iclass 3/0
uhid2 at uhidev4: input=18, output=27, feature=0
uaudio0 at uhub2 port 4 configuration 1 interface 1 HA INFO HA INFO U2 USB TO 
SPDIF rev 1.10/0.01 addr 5
uaudio0: ignored setting with type 8193 format
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0

=== Lindy USB 2.0 Audio Adapter Pro
uaudio0 at uhub2 port 4 configuration 1 interface 0 ABC C-Media USB Headphone 
Set rev 1.10/1.00 addr 5
uaudio0: audio rev 1.00, 8 mixer controls
audio1 at uaudio0
uhidev4 at uhub2 port 4 configuration 1 interface 3 ABC C-Media USB Headphone 
Set rev 1.10/1.00 addr 5
uhidev4: iclass 3/0
uhid2 at uhidev4: input=4, output=4, feature=0

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: uaudio useless?

2014-05-18 Thread Kevin Chadwick

previously on this list Christian Weisgerber contributed:

 Maybe
 there are audio dongles that run at hi-speed, otherwise uaudio(4)
 looks pretty useless.

I may have one as it supports DSD however it comes up as ugen currently
so I am not sure if it would use uaudio until I have the time to look
into how much I can get to work with OpenBSD.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___

uaudio useless?

2014-05-17 Thread Christian Weisgerber

I just tried to hang a USB audio dongle off my spiffy new machine,
and was rudely reminded of this long-standing issue:

  ehci0: Error opening low/full speed isoc endpoint.
  A low/full speed device is attached to a USB2 hub, and transaction
  translations are not yet supported.

Right.  I had seen this before but forgotten about it, and the
previous box where I had successfully tested this uaudio device
happened to be my Sun Blade 100, which only has USB1.1 to begin
with.

So it seems it is currently impossible to run any uaudio(4) device
that only supports USB1 speeds on a machine with USB2 ports.  Maybe
there are audio dongles that run at hi-speed, otherwise uaudio(4)
looks pretty useless.

Hmpf.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: Interrupts cause uaudio stuttering with mpd

2013-10-03 Thread Alex Holst

Quoting Alexandre Ratchov (a...@caoua.org):
 Is this the graphic-mode console or bare 80x25 text-mode console?

This is bare 80x25 text-mode console. Yes, yes. I know. I'm a freak.

aucat -i foo.wav has the same stuttering when the console is used and
the same random stuttering when i/o occurs. 

Is there a particular thing I can try now?


-- 
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow.http://a.mongers.org

Re: Interrupts cause uaudio stuttering with mpd

2013-10-03 Thread Eric Johnson

On Thu, 3 Oct 2013, Alex Holst wrote:

 This is bare 80x25 text-mode console. Yes, yes. I know. I'm a freak.

Freak?

I do my best work on an inexpensive VT-100 compatible I bought on eBay for 
$60 a few years ago.  It was brand new out of the box, but put in the box 
something like ten years prior to that.  It's a whole lot less distracting 
than a regular monitor -- keeps me from being distracted by web site 
ydiscussions.

Eric

Re: Interrupts cause uaudio stuttering with mpd

2013-09-30 Thread Alexandre Ratchov

On Sun, Sep 29, 2013 at 11:28:26AM +0200, Alex Holst wrote:
 I'm looking for input on solving a long-standing issue with uaudio
 playback on my desktop system. (http://mongers.org/openbsd/dmesg.fit)
 
 When playing local FLAC files or streaming ogg/mp3 through mpd (or
 cvlc), I experience stuttering when system interrupts spike above 15% --
 the most reliable way I can reproduce this is by forcing a bit of disk
 i/o.

do you know what causes these interrupts? is this the uaudio
device? (ex try systat -s1 vmstat)

 Back in April I tried Alexandre's patch related to audio/midi interrupts
 on mp kernels.

This diff is now in, but something else is still causing interrupts
to be missed on MP systems. Furthermore uaudio uses the usb
sub-system which always grabs the kernel_lock and consequently will
miss interrupts.

 I also tried sndiod -r44100 -z2940 but neither made any
 difference. 
 
 Is the stuttering likely related to my hardware, is it a known problem
 or is there something else I can try?

uaudio driver is known to not work very well (lack of time to
clean-up the driver). But I don't know if that's causing the
stuttering you observe. There may be multiple causes :(

You could try find the cause:

 - switch into using the GENERIC kernel and see if
   stuttering is affected

 - use trivial tools to play audio (eg. aucat -i foo.wav) during
   the tests.

 - does the -mplay option affect stuttering? if so the
   cause may be the uaudio driver.

thanks

-- Alexandre

Re: Interrupts cause uaudio stuttering with mpd

2013-09-30 Thread Alex Holst

Quoting Alexandre Ratchov (a...@caoua.org):
 do you know what causes these interrupts? is this the uaudio
 device? (ex try systat -s1 vmstat)

It's never the uaudio device, in fact it's not even one of the devices
listed in that view.  I have uhci2 which hovers around 62.

re0 hovers around 300 but briefly spikes during heavy network usage. ipi
hovers around 4-600, then spikes to 15000.

ipi seems to be an MP thing; it's not present in GENERIC.

  Is the stuttering likely related to my hardware, is it a known problem
  or is there something else I can try?
 
  - switch into using the GENERIC kernel and see if
stuttering is affected
 
  - use trivial tools to play audio (eg. aucat -i foo.wav) during
the tests.
 
  - does the -mplay option affect stuttering? if so the
cause may be the uaudio driver.

Adding -mplay to sndiod_flags and restarting sndiod didn't help.
Then I rebooted into GENERIC and there seemed to be longer between
stuttering (suggesting it didn't get triggered quite as easily).

I wasn't kidding when I said this is my desktop system but I don't run X
because this chipset is shit. I am in console most of the time. I
discovered *any* output to console, even if I haven't switched to that
tty could cause a small glitch in the audio. It's sporadic but more
output is definately worse. Scrolling quickly through man pages is
annoying and running 'make clean' made the audio unbearable.

Logging out of the console and ssh'ing from another system has made the
stuttering much more infrequent (once every 20-30mins instead of every 2
minutes) and it doesn't seem related to scrolling in man nor to what
make is up to. Does that make any sense at all?

I'll look into playing wav files with aucat and let you know.

-- 
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow.http://a.mongers.org

Re: Interrupts cause uaudio stuttering with mpd

2013-09-30 Thread Alexandre Ratchov

On Mon, Sep 30, 2013 at 10:19:09PM +0200, Alex Holst wrote:
 
 I wasn't kidding when I said this is my desktop system but I don't run X
 because this chipset is shit. I am in console most of the time. I
 discovered *any* output to console, even if I haven't switched to that
 tty could cause a small glitch in the audio. It's sporadic but more
 output is definately worse. Scrolling quickly through man pages is
 annoying and running 'make clean' made the audio unbearable.

Is this the graphic-mode console or bare 80x25 text-mode console?
The dmesg doesn't show any drm devices.

FWIW, the graphic console runs in kernel mode, so it somewhat
breaks audio. That's something being worked on, but still doesn't
work yet.

 Logging out of the console and ssh'ing from another system has made the
 stuttering much more infrequent (once every 20-30mins instead of every 2
 minutes) and it doesn't seem related to scrolling in man nor to what
 make is up to. Does that make any sense at all?

Yes it does.

-- Alexandre

Re: Interrupts cause uaudio stuttering with mpd

2013-09-30 Thread opendaddy

Is this the Akai MPD18 or 24?

O.D.

Interrupts cause uaudio stuttering with mpd

2013-09-29 Thread Alex Holst

I'm looking for input on solving a long-standing issue with uaudio
playback on my desktop system. (http://mongers.org/openbsd/dmesg.fit)

When playing local FLAC files or streaming ogg/mp3 through mpd (or
cvlc), I experience stuttering when system interrupts spike above 15% --
the most reliable way I can reproduce this is by forcing a bit of disk
i/o.

Back in April I tried Alexandre's patch related to audio/midi interrupts
on mp kernels. I also tried sndiod -r44100 -z2940 but neither made any
difference. 

Is the stuttering likely related to my hardware, is it a known problem
or is there something else I can try?

-- 
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow.http://a.mongers.org

Re: Interrupts cause uaudio stuttering with mpd

2013-09-29 Thread Paul Kelly

On 29/09/2013 7:28 PM, Alex Holst wrote:
 I'm looking for input on solving a long-standing issue with uaudio
 playback on my desktop system. (http://mongers.org/openbsd/dmesg.fit)
 
 When playing local FLAC files or streaming ogg/mp3 through mpd (or
 cvlc), I experience stuttering when system interrupts spike above 15% --
 the most reliable way I can reproduce this is by forcing a bit of disk
 i/o.
 
 Back in April I tried Alexandre's patch related to audio/midi interrupts
 on mp kernels. I also tried sndiod -r44100 -z2940 but neither made any
 difference. 
 
 Is the stuttering likely related to my hardware, is it a known problem
 or is there something else I can try?

Sounds quite similar to this:
http://marc.info/?l=openbsd-miscm=137935068413841w=2

If that is the case then I guess that upgrading from the Atom to a
faster CPU might alleviate your symptoms, though difficult for me to say
because the underlying issue sounds very complex.


paul

Re: Focusrite Scarlett 2i2 and uaudio error 4 audio descriptors make no sense

2013-09-03 Thread Remco

gjones wrote:

The Focusrite Scarlett 2i2 gives me an uaudio error=4 audio descriptors
make no sense

Googling, there was a patch made to Freebsd's uaudio last April,

http://freebsd.1045724.n5.nabble.com/snd-uaudio-2-0-class-support-for-24-bit-samples-with-bSubslotSize-4-td5806141.html;

but I am unable to figure out how to translate this into a patch for
OpenBSD's uaudio.c.

I don't think this is the problem.

Can anyone point me in the right direction?

Greg
__

$ usbdevs -a 3 -d -v
Controller /dev/usb0:
addr 3: high speed, power 500 mA, config 1, Scarlett 2i2 USB(0x8006),
Focusrite(0x1235), rev 0.cc
uaudio0
ugen0
_

from dmesg:

ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int
16 usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
.
.
.
.
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uaudio0 at uhub2 port 1 configuration 1 interface 0 Focusrite Scarlett
2i2 USB rev 2.00/0.cc addr 3
uaudio0: audio descriptors make no sense, error=4
ugen0 at uhub2 port 1 configuration 1 Focusrite Scarlett 2i2 USB rev
2.00/0.cc addr 3

AFAICT this fails during detection of the device, the uaudio driver isn't able
to interpret your device's USB descriptors.

Looking at the FreeBSD post, your device seems to adhere to the USB Audio 2.0
specification. I don't think OpenBSD has support for USB Audio 2.0 and that's
the reason it fails to detect your device. (note that USB Audio 2.0 is NOT
the same as USB 2.0, for which OpenBSD DOES have support)

Focusrite Scarlett 2i2 and uaudio error 4 audio descriptors make no sense

2013-09-02 Thread gjones

The Focusrite Scarlett 2i2 gives me an uaudio error=4 audio descriptors make no 
sense


Googling, there was a patch made to Freebsd's uaudio last April,

http://freebsd.1045724.n5.nabble.com/snd-uaudio-2-0-class-support-for-24-bit-samples-with-bSubslotSize-4-td5806141.html;

but I am unable to figure out how to translate this into a patch for OpenBSD's 
uaudio.c.


Can anyone point me in the right direction?

Greg
__

$ usbdevs -a 3 -d -v
Controller /dev/usb0:
addr 3: high speed, power 500 mA, config 1, Scarlett 2i2 USB(0x8006), 
Focusrite(0x1235), rev 0.cc

  uaudio0
  ugen0
_

from dmesg:

ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
.
.
.
.
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uaudio0 at uhub2 port 1 configuration 1 interface 0 Focusrite Scarlett 2i2 USB 
rev 2.00/0.cc addr 3

uaudio0: audio descriptors make no sense, error=4
ugen0 at uhub2 port 1 configuration 1 Focusrite Scarlett 2i2 USB rev 2.00/0.cc 
addr 3

Re: record off of uaudio device (help?)

2012-02-19 Thread Remco

patrick keshishian wrote:

 I should have been more specific with my question and subject line: I
 don't see where aucat's -f device values are documented.
 
I suppose you overlooked sndio(7).

 Googling finds old (google-cached) current.html pages, circa 2009,
 suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at
 first failed:
 
 $ aucat -f sun:1 -m rec -o /tmp/test.wav
 sio(sun:1|): busy loop, disconnecting
 
This should work, unfortunately (according to ratchov@) there's possibly a
bug in the (obscure) buffering of USB audio devices which makes this fail
for some devices. (Mine happens to be 2-ch, 24-bit @ 44100 Hz, in case that
matters)

 A bit more googling finds this post[1] suggesting addition of -z 256
 to aucat, which seems to make things work.
 
 $ aucat -z 256 -f sun:1 -o /tmp/test.wav
 ^C
 
So, yes, in this case it's necessary to specify a buffer size. (in my
experience many buffer sizes will work, the one aucat calculates just
doesn't)

Re: record off of uaudio device (help?)

2012-02-19 Thread patrick keshishian

On Sun, Feb 19, 2012 at 12:54 AM, Remco re...@d-compu.dyndns.org wrote:
 patrick keshishian wrote:

 I should have been more specific with my question and subject line: I
 don't see where aucat's -f device values are documented.

 I suppose you overlooked sndio(7).

Nope, I read that page. There is no mention of 'sun:x' in that page.
There is, however, a reference to 'rsnd/0' being 'First hardware audio
device', but trying it and having it fail (before learning of '-z
nframes' option) brought me to misc@. I think this can be documented
better in aucat(1) with a concrete example or two.

--patrick


 Googling finds old (google-cached) current.html pages, circa 2009,
 suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at
 first failed:

 $ aucat -f sun:1 -m rec -o /tmp/test.wav
 sio(sun:1|): busy loop, disconnecting

 This should work, unfortunately (according to ratchov@) there's possibly a
 bug in the (obscure) buffering of USB audio devices which makes this fail
 for some devices. (Mine happens to be 2-ch, 24-bit @ 44100 Hz, in case that
 matters)

 A bit more googling finds this post[1] suggesting addition of -z 256
 to aucat, which seems to make things work.

 $ aucat -z 256 -f sun:1 -o /tmp/test.wav
 ^C

 So, yes, in this case it's necessary to specify a buffer size. (in my
 experience many buffer sizes will work, the one aucat calculates just
 doesn't)

Re: record off of uaudio device (help?)

2012-02-19 Thread Remco

On Sunday 19 February 2012 11:32:25 you wrote:
 On Sun, Feb 19, 2012 at 12:54 AM, Remco re...@d-compu.dyndns.org wrote:
  patrick keshishian wrote:
  I should have been more specific with my question and subject line: I
  don't see where aucat's -f device values are documented.
 
  I suppose you overlooked sndio(7).

 Nope, I read that page. There is no mention of 'sun:x' in that page.
 There is, however, a reference to 'rsnd/0' being 'First hardware audio
 device', but trying it and having it fail (before learning of '-z
 nframes' option) brought me to misc@. I think this can be documented
 better in aucat(1) with a concrete example or two.

 --patrick

I missed that you're running CURRENT (I was referring to 5.0). AFAICT the 
sun:x names are deprecated in CURRENT though they may still work. I think you 
should be able to access the device by the 'rsnd/1' name, albeit specifying 
the buffer size would still be a necessity.

Re: record off of uaudio device (help?)

2012-02-19 Thread Jan Stary

On Feb 18 16:59:32, patrick keshishian wrote:
 Can someone point me to some docs explaining how I can record off of a
 uaudio device I plugged in?

Same as with any other device:
http://www.openbsd.org/faq/faq13.html#recordaudio

 [after plugging in uaudio device]
 uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
 Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
 uaudio0: audio rev 1.00, 3 mixer controls
 audio1 at uaudio0
 
 now what?

man aucat
man sndio, see DEVICE NAMES
aucat -f snd/1 -o /tmp/rec.wav

On Feb 18 22:36:45, patrick keshishian wrote:
 I should have been more specific with my question and subject line: I
 don't see where aucat's -f device values are documented.

In man sndio(7), which man aucat(1) tells you to read.

 Googling finds old (google-cached) current.html pages, circa 2009,

Howls of derisive laughter, Bruce!

 A bit more googling finds this post[1] suggesting addition of -z 256
 [1] http://old.nabble.com/aucat-bug-in-4.8-beta-i386---td29333138.html
 to aucat, which seems to make things work.
 $ aucat -z 256 -f sun:1 -o /tmp/test.wav

-z specifies the blocksize;
that alone doesn't make the audio device record or not.

Also, a lot has changed in sndio since 4.8 beta.
Don't google around, just read the FM.

record off of uaudio device (help?)

2012-02-18 Thread patrick keshishian

Can someone point me to some docs explaining how I can record off of a
uaudio device I plugged in?

[after plugging in uaudio device]
uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
uaudio0: audio rev 1.00, 3 mixer controls
audio1 at uaudio0

now what?

$ audioctl -f /dev/audioctl1
name=USB audio
version=
config=uaudio
encodings=slinear_le:24:3:1
properties=full_duplex
full_duplex=0
fullduplex=0
blocksize=13216
hiwat=4
lowat=1
output_muted=0
monitor_gain=0
mode=
play.rate=44100
play.sample_rate=44100
play.channels=2
play.precision=24
play.bps=3
play.msb=1
play.encoding=slinear_le
play.gain=255
play.balance=32
play.port=0x0
play.avail_ports=0x0
play.seek=0
play.samples=0
play.eof=0
play.pause=0
play.error=0
play.waiting=0
play.open=0
play.active=0
play.buffer_size=65536
play.block_size=13216
play.errors=0
record.rate=44100
record.sample_rate=44100
record.channels=2
record.precision=24
record.bps=3
record.msb=1
record.encoding=slinear_le
record.gain=127
record.balance=32
record.port=0x0
record.avail_ports=0x0
record.seek=0
record.samples=0
record.eof=0
record.pause=1
record.error=0
record.waiting=0
record.open=0
record.active=0
record.buffer_size=65536
record.block_size=17632
record.errors=0

$ mixerctl -v -f /dev/mixer1
inputs.dac.mute=off  [ off on ]
inputs.dac=255,255 volume
outputs.ext12-enable=off  [ off on ]

$ sysctl kern.version
kern.version=OpenBSD 5.0-current (GENERIC) #121: Mon Nov 28 16:00:51 MST 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Re: record off of uaudio device (help?)

2012-02-18 Thread Tomas Bodzar

On Sun, Feb 19, 2012 at 1:59 AM, patrick keshishian pkesh...@gmail.com
wrote:
 Can someone point me to some docs explaining how I can record off of a
 uaudio device I plugged in?

 [after plugging in uaudio device]
 uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
 Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
 uaudio0: audio rev 1.00, 3 mixer controls
 audio1 at uaudio0

 now what?

http://www.openbsd.org/faq/faq13.html#recordaudio

don't specify -f for your commands so we can't see what inputs/outputs
are in use by system


 $ audioctl -f /dev/audioctl1
 name=USB audio
 version=
 config=uaudio
 encodings=slinear_le:24:3:1
 properties=full_duplex
 full_duplex=0
 fullduplex=0
 blocksize=13216
 hiwat=4
 lowat=1
 output_muted=0
 monitor_gain=0
 mode=
 play.rate=44100
 play.sample_rate=44100
 play.channels=2
 play.precision=24
 play.bps=3
 play.msb=1
 play.encoding=slinear_le
 play.gain=255
 play.balance=32
 play.port=0x0
 play.avail_ports=0x0
 play.seek=0
 play.samples=0
 play.eof=0
 play.pause=0
 play.error=0
 play.waiting=0
 play.open=0
 play.active=0
 play.buffer_size=65536
 play.block_size=13216
 play.errors=0
 record.rate=44100
 record.sample_rate=44100
 record.channels=2
 record.precision=24
 record.bps=3
 record.msb=1
 record.encoding=slinear_le
 record.gain=127
 record.balance=32
 record.port=0x0
 record.avail_ports=0x0
 record.seek=0
 record.samples=0
 record.eof=0
 record.pause=1
 record.error=0
 record.waiting=0
 record.open=0
 record.active=0
 record.buffer_size=65536
 record.block_size=17632
 record.errors=0

 $ mixerctl -v -f /dev/mixer1
 inputs.dac.mute=off B [ off on ]
 inputs.dac=255,255 volume
 outputs.ext12-enable=off B [ off on ]

 $ sysctl kern.version
 kern.version=OpenBSD 5.0-current (GENERIC) #121: Mon Nov 28 16:00:51 MST
2011
 B  B dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Re: record off of uaudio device (help?)

2012-02-18 Thread patrick keshishian

I should have been more specific with my question and subject line: I
don't see where aucat's -f device values are documented.

Googling finds old (google-cached) current.html pages, circa 2009,
suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at
first failed:

$ aucat -f sun:1 -m rec -o /tmp/test.wav
sio(sun:1|): busy loop, disconnecting

A bit more googling finds this post[1] suggesting addition of -z 256
to aucat, which seems to make things work.

$ aucat -z 256 -f sun:1 -o /tmp/test.wav
^C

--patrick

[1] http://old.nabble.com/aucat-bug-in-4.8-beta-i386---td29333138.html

On Sat, Feb 18, 2012 at 4:59 PM, patrick keshishian pkesh...@gmail.com
wrote:
 Can someone point me to some docs explaining how I can record off of a
 uaudio device I plugged in?

 [after plugging in uaudio device]
 uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
 Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
 uaudio0: audio rev 1.00, 3 mixer controls
 audio1 at uaudio0

 now what?

 $ audioctl -f /dev/audioctl1
 name=USB audio
 version=
 config=uaudio
 encodings=slinear_le:24:3:1
 properties=full_duplex
 full_duplex=0
 fullduplex=0
 blocksize=13216
 hiwat=4
 lowat=1
 output_muted=0
 monitor_gain=0
 mode=
 play.rate=44100
 play.sample_rate=44100
 play.channels=2
 play.precision=24
 play.bps=3
 play.msb=1
 play.encoding=slinear_le
 play.gain=255
 play.balance=32
 play.port=0x0
 play.avail_ports=0x0
 play.seek=0
 play.samples=0
 play.eof=0
 play.pause=0
 play.error=0
 play.waiting=0
 play.open=0
 play.active=0
 play.buffer_size=65536
 play.block_size=13216
 play.errors=0
 record.rate=44100
 record.sample_rate=44100
 record.channels=2
 record.precision=24
 record.bps=3
 record.msb=1
 record.encoding=slinear_le
 record.gain=127
 record.balance=32
 record.port=0x0
 record.avail_ports=0x0
 record.seek=0
 record.samples=0
 record.eof=0
 record.pause=1
 record.error=0
 record.waiting=0
 record.open=0
 record.active=0
 record.buffer_size=65536
 record.block_size=17632
 record.errors=0

 $ mixerctl -v -f /dev/mixer1
 inputs.dac.mute=off  [ off on ]
 inputs.dac=255,255 volume
 outputs.ext12-enable=off  [ off on ]

 $ sysctl kern.version
 kern.version=OpenBSD 5.0-current (GENERIC) #121: Mon Nov 28 16:00:51 MST
2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Re: record off of uaudio device (help?)

2012-02-18 Thread Tomas Bodzar

On Sun, Feb 19, 2012 at 7:36 AM, patrick keshishian pkesh...@gmail.com
wrote:
 I should have been more specific with my question and subject line: I
 don't see where aucat's -f device values are documented.

 Googling finds old (google-cached) current.html pages, circa 2009,
 suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at
 first failed:

No. I mean post output of mixerctl -v and audioctl -v ;-) Don't use
Google for something what is much more better documented inside system
itself
http://www.openbsd.org/cgi-bin/man.cgi?query=aucatapropos=0sektion=0manpat
h=OpenBSD+5.0arch=i386format=html


 $ aucat -f sun:1 -m rec -o /tmp/test.wav
 sio(sun:1|): busy loop, disconnecting

 A bit more googling finds this post[1] suggesting addition of -z 256
 to aucat, which seems to make things work.

 $ aucat -z 256 -f sun:1 -o /tmp/test.wav
 ^C

 --patrick

 [1] http://old.nabble.com/aucat-bug-in-4.8-beta-i386---td29333138.html

 On Sat, Feb 18, 2012 at 4:59 PM, patrick keshishian pkesh...@gmail.com
 wrote:
 Can someone point me to some docs explaining how I can record off of a
 uaudio device I plugged in?

 [after plugging in uaudio device]
 uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
 Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
 uaudio0: audio rev 1.00, 3 mixer controls
 audio1 at uaudio0

 now what?

 $ audioctl -f /dev/audioctl1
 name=USB audio
 version=
 config=uaudio
 encodings=slinear_le:24:3:1
 properties=full_duplex
 full_duplex=0
 fullduplex=0
 blocksize=13216
 hiwat=4
 lowat=1
 output_muted=0
 monitor_gain=0
 mode=
 play.rate=44100
 play.sample_rate=44100
 play.channels=2
 play.precision=24
 play.bps=3
 play.msb=1
 play.encoding=slinear_le
 play.gain=255
 play.balance=32
 play.port=0x0
 play.avail_ports=0x0
 play.seek=0
 play.samples=0
 play.eof=0
 play.pause=0
 play.error=0
 play.waiting=0
 play.open=0
 play.active=0
 play.buffer_size=65536
 play.block_size=13216
 play.errors=0
 record.rate=44100
 record.sample_rate=44100
 record.channels=2
 record.precision=24
 record.bps=3
 record.msb=1
 record.encoding=slinear_le
 record.gain=127
 record.balance=32
 record.port=0x0
 record.avail_ports=0x0
 record.seek=0
 record.samples=0
 record.eof=0
 record.pause=1
 record.error=0
 record.waiting=0
 record.open=0
 record.active=0
 record.buffer_size=65536
 record.block_size=17632
 record.errors=0

 $ mixerctl -v -f /dev/mixer1
 inputs.dac.mute=off B [ off on ]
 inputs.dac=255,255 volume
 outputs.ext12-enable=off B [ off on ]

 $ sysctl kern.version
 kern.version=OpenBSD 5.0-current (GENERIC) #121: Mon Nov 28 16:00:51 MST
 2011
 B  B dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Re: record off of uaudio device (help?)

2012-02-18 Thread patrick keshishian

On Sat, Feb 18, 2012 at 10:57 PM, Tomas Bodzar tomas.bod...@gmail.com
wrote:
 On Sun, Feb 19, 2012 at 7:36 AM, patrick keshishian pkesh...@gmail.com
wrote:
 I should have been more specific with my question and subject line: I
 don't see where aucat's -f device values are documented.

 Googling finds old (google-cached) current.html pages, circa 2009,
 suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at
 first failed:

 No. I mean post output of mixerctl -v and audioctl -v ;-) Don't use
 Google for something what is much more better documented inside system
 itself
http://www.openbsd.org/cgi-bin/man.cgi?query=aucatapropos=0sektion=0manpat
h=OpenBSD+5.0arch=i386format=html

are _you_ /certain/ of what you speak?

--patrick



 $ aucat -f sun:1 -m rec -o /tmp/test.wav
 sio(sun:1|): busy loop, disconnecting

 A bit more googling finds this post[1] suggesting addition of -z 256
 to aucat, which seems to make things work.

 $ aucat -z 256 -f sun:1 -o /tmp/test.wav
 ^C

 --patrick

 [1] http://old.nabble.com/aucat-bug-in-4.8-beta-i386---td29333138.html

 On Sat, Feb 18, 2012 at 4:59 PM, patrick keshishian pkesh...@gmail.com
 wrote:
 Can someone point me to some docs explaining how I can record off of a
 uaudio device I plugged in?

 [after plugging in uaudio device]
 uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems,
 Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3
 uaudio0: audio rev 1.00, 3 mixer controls
 audio1 at uaudio0

 now what?

 $ audioctl -f /dev/audioctl1
 name=USB audio
 version=
 config=uaudio
 encodings=slinear_le:24:3:1
 properties=full_duplex
 full_duplex=0
 fullduplex=0
 blocksize=13216
 hiwat=4
 lowat=1
 output_muted=0
 monitor_gain=0
 mode=
 play.rate=44100
 play.sample_rate=44100
 play.channels=2
 play.precision=24
 play.bps=3
 play.msb=1
 play.encoding=slinear_le
 play.gain=255
 play.balance=32
 play.port=0x0
 play.avail_ports=0x0
 play.seek=0
 play.samples=0
 play.eof=0
 play.pause=0
 play.error=0
 play.waiting=0
 play.open=0
 play.active=0
 play.buffer_size=65536
 play.block_size=13216
 play.errors=0
 record.rate=44100
 record.sample_rate=44100
 record.channels=2
 record.precision=24
 record.bps=3
 record.msb=1
 record.encoding=slinear_le
 record.gain=127
 record.balance=32
 record.port=0x0
 record.avail_ports=0x0
 record.seek=0
 record.samples=0
 record.eof=0
 record.pause=1
 record.error=0
 record.waiting=0
 record.open=0
 record.active=0
 record.buffer_size=65536
 record.block_size=17632
 record.errors=0

 $ mixerctl -v -f /dev/mixer1
 inputs.dac.mute=off  [ off on ]
 inputs.dac=255,255 volume
 outputs.ext12-enable=off  [ off on ]

 $ sysctl kern.version
 kern.version=OpenBSD 5.0-current (GENERIC) #121: Mon Nov 28 16:00:51 MST
 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

82 matches

Mail list logo