Xen project Mailing List

Arjen, Could you tell me a little more about your setup, I'm looking to set up something similar myself

Do you have X in the dom0? I'm having a hard time getting X to work with the fglrx drivers in a gentoo dom0

Are you running openSuse, Ubuntu as PV or (PV)HVM guests?

Are you using the fglrx or radeon drivers?

- OJ

On Sat, May 11, 2013 at 3:21 PM, Arjen <arjenvanweelden@xxxxxxxxx> wrote:

Hi Andrew,

Thanks for your comments on BDF notation, it is now clear to me that everything except the Radeon is on the same PCIe bus 00. So far, this has not been a problem with passthrough such as USB.

I'm more and more convinces that the Alsa underrun is a performance/timing issue and that I just can't configure the right period buffer size or something. I guess detailed questions about Alsa are for another mailing list...

I didn't realize you were talking about a SB X-Fi via USB, there seems to be many different models with similar names. I might just take you up on your offer for some testing if I decide to give up on the onboard audio.

If you are thinking about getting a HD7xx0, please note that my HIS HD7750 prevents the domU from rebooting. Looks like the fglrx driver (no open source driver available yet) does not "turn off" the VGA. The display keeps sending a blank screen to the display. It then cannot initialize the VGA during a restart. I think I can live with the work-around that I have to reboot the dom0 as well, until AMD fixes the driver. I disabled the VGA passthrough for now, as troubleshooting this sound issue often requires a reboot.

Thanks for your quick responses, and have a good (and quiet) weekend!

On 11-05-13 12:23, Andrew Bobulsky wrote:

Hello again Arjen,

I'll write my answers in line below:

On May 11, 2013, at 5:04 AM, Arjen <arjenvanweelden@xxxxxxxxx
<mailto:arjenvanweelden@xxxxxxxxx>> wrote:

Hello Andrew,

Thank you for your answer. That sounds very similar to how I solved my
VGA passthrough: I bought a HD7750 because I couldn't get my GTX550 to
work. Because of the closed binary drivers, I didn't see another option.

I'm eyeballing Radeon 7 series cards myself... Just for Xen, too ;)

I would like to use 5.1 and SP/DIF output, and I do have a PCIe x4
empty at the moment. A Sound Blaster X-Fi Xtreme Audio might do the
trick. Creative does not seem to support Linux but if I read you
right, it works well with Linux?

Optical audio is a funny thing. I think it allows a sound device to add
it at nearly zero computational cost---audio gets encoded to AC3 or DTS
or whatever by the computer and piped out of a "dumb" port where the
receiver goes on to do all the fun DAC work. As a result, pretty much
all of the ultra cheap USB devices support toslink, usually through a
micro(?) SPDIF output combined into the 1/8" jack, the same way Apple's
computers have for a good while now.

I've used the optical connection on the X-Fi though, and know it works
well... at least in Windows. ;). If you're considering buying it and
need me to run a test on something, just drop me a line and I'll do what
I can for you. ...and if you'd like me to reaffirm, it /does/ work on

Linux by virtue of being a USB audio device. It's got some special
features and a big knob on it and stuff but I can't say whether those
would ever work in Linux; not that you'd need them of course!

There is still the option of emulating a soundcard via Xen, but I find
it hard to find any documentation on the requirements of the dom0. I
suppose it need alsa installed? It is possible to emulate a 5.1
soundcard? Could you point me to more documentation?

No clue on that one. The list tends to be pretty quiet on the weekend
so I figured I'd try to give you a solution that'd work before Monday
afternoon ;)

Regarding your remark about PCI being hit or miss: How can I check
whether the onboard device is a PCI (or behind a PCIe-PCI bridge)?

OH yes. If I'm not mistaken, devices are in BDF notation, which
literally works like: [domain:]bus:device.function

Domain tends to be omitted a lot, as its nearly always "0000" in these
situations. Anyway, if you do "lspci -vtQ" you'll get a hierarchical
layout of the devices on your pci bus, or just "lspci -vQ" for an easy
to read list. Back to BDF notation, remember bus:device.function? PCIe
devices are always(?) device 0 on their own buses. They sometimes have
multiple functions, like .0 and .1, but the device will be "device 0" on
a uniquely numbered bus---find your Radeon in the list and you'll see it
has two functions coming from device 0, but there will be no device 1 on
the same bus.

A PCI device on the other hand is often sitting alongside other devices
on the same bus, and if we look back at your sound device, "00:1b.0,"
you can see we have bus 0, device 1b, function 0. Since it's not device
0 on its bus, that tells me its a PCI device. (I'm a little foggy on
the specifics, but I think all PCI devices get shoved on bus 0).

With PCI devices, while you /can/ pass them to VMs, you basically need

to treat the whole bus---and every device on it---as a single entity.
That pretty much means you need to find everything else on the bus
and, at the very least, make sure pciback has control of them
all---which will probably disconnect something your Dom0 won't want to
miss!---or possibly it may require that all of those devices be passed
to that same vm as well. Something about PCI being old as dirt makes
the compromise necessary for the IOMMU to be "guaranteed" to work.

I'm sorry to bother you will all those questions. It's just that I
still feel very close to getting this onboard audio to work as it
already outputs recognizable sound, besides the buffer underrun issues.

Thanks for pointing out SB X-Fi as good last resort.

Not a problem! This is what mailing lists are for! Good questions and
the mighty Google just help us all keep paying it forward as we can ;)

Cheers,
Andrew

On 11-05-13 09:47, Andrew Bobulsky wrote:

Hello Arjen,

On Sat, May 11, 2013 at 2:32 AM, Arjen <arjenvanweelden@xxxxxxxxx
<mailto:arjenvanweelden@xxxxxxxxx>
<mailto:arjenvanweelden@xxxxxxxxx>> wrote:

<snip>

I'm looking for suggestions on how to proceed. What logs should I
inspect, what settings need checking? Might it be better to use Qemu
sound emulation? Should I try XCP instead of my current dom0? Can
someone point me towards more documentation about audio passthrough?

I've often noticed that onboard audio devices tend to be hung off of a
PCI bus instead of a PCIe bus. Sometimes they use a PCIe-PCI bridge,
but either way, passing things hanging off of PCI has been a hit or miss
affair every time I've tried, and it's never really been stable.

You said you've passed USB ports properly, and when faced with a similar
problem, I solved it with one of these:
http://www.amazon.com/Turtle-Beach-Advantage-Headset-Adapter/dp/B0036VO4XO

USB audio works really, really well, and even the super cheap adapters
are quite functional... though I've seen their mic inputs susceptible to
interference. Nonetheless, if you don't want to "tech" your way out of
the problem and really love cheap solutions, you should be able to find
adapters of varying quality for about $3 or so, up to $80-ish. After
$20 or so, you're probably paying for more audio
outputs/mixers/brand-name or something---the Sound Blaster X-Fi is a
good example there; I've got one and it works great in Debian Linux with
ALSA, ports and hookups all over the thing, too! :)

Cheers,
Andrew Bobulsky

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

Re: [Xen-users] Audio PCI passthrough issues in a Linux domU