search for: usbaudio

...tabase Version: 1.2.32 Severity: wishlist Ignore rules to supress messages generated from pugging in, and then removing, a USB headset (one speaker). ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: drivers\/usb\/class\/audio\.c: v1.0.0:USB Audio Class driver$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: usbaudio: assuming that a stereo channel connected directly to a mixer is missing in search.*$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: usbaudio: constructing mixer for Terminal [0-9]+ type 0x[0-9]+$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: usbaudio: device [0-9] audiocontrol interface [0-9] has [0-9] i...

Is it possible ot have multiple contexts in alsa.conf [general] autoanswer=yes input_device=hw:0,0 output_device=hw:0,0 [usbaudio] autoanswer=yes input_device=hw:1,0 output_device=hw:1,0 is Dial(Console/usbaudio) valid? I presume Dial(Console/dsp) uses the default or general context above. how do you direct a call to the second ALSA device usbaudio? Thanks, jerry

Hi, I have been trying to figure out why the S100U is not performing very well on RH9.. Here is my thinking..( may be totally wide of the mark but here goes anyway) I remember reading somwhere that the sound system used by RH has changed... Does the S100U not depend on the sound subsystem?? So what I think is that the sound subsystem in RH9 and the S100U are not happy working together.. Does

...rk with my Logitech mic. For the record I have it (the microphone, that is) set up so that it works fine in Audacity. After opining Wine configure, dmesg gives me lots of these: [ yadda. yadda*] ALSA /build/buildd/linux-ubuntu-modules-2.6.24-2.6.24/debian/build/build-generic/sound/alsa-driver/usb/usbaudio.c:1345: 4:1:1: usb_set_interface failed *yadda. yadda being a string of 4numbers, followed by 6numbers. I realize that this info might be entirely useless, but I knowing as little as I do, I assume that they are related. -Thanks

...s_cpu_threads : int option; + s_cpu_topology : source_cpu_topology option; s_features : string list; s_firmware : source_firmware; s_display : source_display option; @@ -102,6 +100,11 @@ and source_sound = { } and source_sound_model = AC97 | ES1370 | ICH6 | ICH9 | PCSpeaker | SB16 | USBAudio +and source_cpu_topology = { + s_cpu_sockets : int; + s_cpu_cores : int; + s_cpu_threads : int; +} let rec string_of_source s = sprintf " source name: %s @@ -110,7 +113,7 @@ hypervisor type: %s nr vCPUs: %d CPU vendor: %s CPU model: %s - CPU topology: sockets...

...Store_field (cons, 1, rv); + rv = cons; + Store_field (cons, 0, v); + + i -= 2; + } + + CAMLreturn (rv); +} diff --git a/v2v/utils.ml b/v2v/utils.ml index 82f4377..636f3c2 100644 --- a/v2v/utils.ml +++ b/v2v/utils.ml @@ -81,6 +81,8 @@ let qemu_supports_sound_card = function | Types.USBAudio -> true +external aavmf_firmware : unit -> (string * string) list = "v2v_utils_aavmf_firmware" + (* Find the UEFI firmware. *) let find_uefi_firmware guest_arch = let files = @@ -96,10 +98,7 @@ let find_uefi_firmware guest_arch = "/usr/share/qemu/ovmf-x86_...

Just refactoring. Rich.

When importing from VMware via the libvirt driver, the libvirt driver can add an empty source bridge name: <interface type='bridge'> <mac address='00:01:02:03:04:05:06'/> <source bridge=''/> </interface> Replicate what we do on the -i ova path, and map these to "eth0", "eth1" etc. This also includes a bunch

First version was posted here: https://www.redhat.com/archives/libguestfs/2016-August/thread.html#00100 This is semantically the same as the first version. However I've split the patch up into two parts. In the first part, I factor out the UEFI paths so now they are created by the generator and written in the library and v2v/ directory directly, instead of the complex business of having a C