|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Audio PCI passthrough issues in a Linux domU
Hi,I hope I'm not offending anyone by replying to myself or for trying KVM instead of Xen... I just tried Intel HD Audio PCI passthrough using openSUSE 12.3 on openSUSE 12.3 KVM and it works flawlessly (with intel_iommu=on). Would anyone like to share their ideas about what I might be doing wrong with my Xen setup, that could cause the same passthrough to produce choppy sound? Where should I look for logging and error messages that help me pinpoint missing kernel or Xen configuration? By the way, does someone have a positive experience with PCI passthrough of a Hauppauge PVR-150 or similar? The device shows up in the domU and ivtv loads fine but recording with mythtv fails. Thanks in advance for any troubleshooting tips. kind regards, Arjen On 11-05-13 15:21, Arjen 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, AndrewOn 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |