Hi everybody, I recently started playing with Xen on new hardware with VT-D support to set up a "personal cloud". I''m running Xen-4.2.1-r2 with a Gentoo dom0 and have an issue with on-board audio PCI passthrough to a domU. I''m setting up my first domU with openSUSE 12.3 and half of my CPU cores and memory as a "desktop VM". The USB controller PCI passthrough and secondary GPU passthrough (AMD HD7750) work fine. I also tested Ubuntu 12.04 and 13.04 and they have the same sound issues as openSUSE, and all have good audio on the real hardware. When I do a PCI passthrough of the onboard 00:1b.0 Intel 7/C210 Series Chipset HD Audio Controller (rev 04), the hardware is available on the domU and detected as snd_hda_intel. Unfortunately, playing sounds results in a lot of skipping, repeating and just generic noise. I tried removing PulseAudio but Alsa also reports "underruns". Thinking it might be a timing or performance issue, I tried pinning the vcpus, enabling/disabling MSI translation and various sched-credit options to no avail. I also tried various snd_hda_intel settings, which did not really improve the sound quality. I didn''t see any interrupt errors on the dom0 or domU. Has anyone experienced a similar issue? Searching the web and mailing lists showed me that other people mostly had other audio issues (as in simply no sound) with a Windows domU. 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? Kind regards, Arjen
Hello Arjen, On Sat, May 11, 2013 at 2:32 AM, Arjen <arjenvanweelden@gmail.com> 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@lists.xen.org http://lists.xen.org/xen-users
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 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? 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? 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)? 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. On 11-05-13 09:47, Andrew Bobulsky wrote:> Hello Arjen, > > On Sat, May 11, 2013 at 2:32 AM, Arjen <arjenvanweelden@gmail.com > <mailto:arjenvanweelden@gmail.com>> 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
Hello again Arjen, I''ll write my answers in line below: On May 11, 2013, at 5:04 AM, Arjen <arjenvanweelden@gmail.com> 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@gmail.com <mailto:arjenvanweelden@gmail.com <arjenvanweelden@gmail.com>>> 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@lists.xen.org http://lists.xen.org/xen-users
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@gmail.com > <mailto:arjenvanweelden@gmail.com>> 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@gmail.com >>> <mailto:arjenvanweelden@gmail.com> >>> <mailto:arjenvanweelden@gmail.com>> 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
Ole Johan Væringstad
2013-May-12 16:05 UTC
Re: Audio PCI passthrough issues in a Linux domU
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@gmail.com> 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@gmail.com >> <mailto:arjenvanweelden@gmail.com>> 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@gmail.com >>>> <mailto:arjenvanweelden@gmail.com> >>>> <mailto:arjenvanweelden@gmail.com>> 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@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hi OJ, I bought an Intel 3770S and an ASRock H77M that provides a working VT-D setup. I run a minimal Gentoo dom0 with efibootmgr, grub2 and xen-4.2.1-r2 (all ~amd) using the onboard Intel HD4000 and a PS/2 keyboard. I have no X installed and are just now setting up Alsa to test the onboard audio on the dom0. OpenSUSE 12.3 runs fine on the bare metal with onboard Intel VGA. My recently bought a HIS Radeon HD7750 iCooler that works using secondary VGA passthrough with decent OpenGL 4 support on OpenSUSE 12.3 HVM. Note that I have to reboot dom0 before restarting this domU. I use the fglrx driver as there are no open source drivers for the HD7xxx''s with OpenGL 3.2 yet. USB2 passthrough works fine. I trying to passthrough the onboard Intel HD Audio as well but am getting very choppy sound in the domU. I successfully run Mythbuntu 12.04.2 (amd64) as a HVM domU with PV drivers, but I have yet to try my Hauppauge PVR-150 PCI tv-card. If that does not work via passthrough, I''ll probably buy a USB2 tv-stick instead. I could also boot Ubuntu 12.04.2 and 13.04 live CD but did not try to install them. For both domU''s I have to specify the boot disk as hda, because Grub won''t boot if I specify it as xvda. I provide the root, home and swap virtual disks via LVM2. Both use PV network drivers and DHCP via my router. The primary VGA is ''stdvga'' because that worked a little better than Cirrus emulation. I currently use a VNC program from another PC to interact with both domU''s. All domU''s use their distribution''s default (desktop) kernels and pci_msitranslate, pci_power_mgmt, xen_platform_pci are enabled. Does this help you, or is there anything more specific that you would like to know? kind regards, Arjen On 12-05-13 18:05, Ole Johan Væringstad wrote:> 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 >(snip)
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@gmail.com >> <mailto:arjenvanweelden@gmail.com>> 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@gmail.com >>>> <mailto:arjenvanweelden@gmail.com> >>>> <mailto:arjenvanweelden@gmail.com>> 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
Hi, I accidentally reproduce my audio passthrough problem in KVM and discovered a work-around for Xen. When I boot dom0 with pciback.hide=(00:1b.0), the passthrough appears to work but the sound playback is choppy and noisy. Instead, I let the snd_hda_intel driver load and own the 00:1b.0 device during the boot of dom0. After starting dom0 I do a xl pci-assignable-add 00:1b.0, which unloads the snd_hda_intel dirver, before starting the domU with PCI passthrough. Apparently, some kind of initialization by the dom0 (or KVM host) is necessary for smooth audio playback in the domU. I don''t know how this fixes my problem, but I hope this work-around might be useful for others with similar sound issues. kind regards, Arjen
Ole Johan Væringstad
2013-May-31 09:31 UTC
Re: Audio PCI passthrough issues in a Linux domU
On Mon, May 20, 2013 at 11:23 AM, Arjen <arjenvanweelden@gmail.com> wrote:> Hi, > > I accidentally reproduce my audio passthrough problem in KVM and discovered > a work-around for Xen. When I boot dom0 with pciback.hide=(00:1b.0), the > passthrough appears to work but the sound playback is choppy and noisy. > > Instead, I let the snd_hda_intel driver load and own the 00:1b.0 device > during the boot of dom0. After starting dom0 I do a > xl pci-assignable-add 00:1b.0, which unloads the snd_hda_intel dirver, > before starting the domU with PCI passthrough. Apparently, some kind of > initialization by the dom0 (or KVM host) is necessary for smooth audio > playback in the domU. > > I don''t know how this fixes my problem, but I hope this work-around might be > useful for others with similar sound issues. > > kind regards, Arjen >Arjen I have got my setup up and running, passing through an Intel C600/X79 HDAC to a Gentoo HVM guest. It works fine with hiding from the kernel, no workarounds needed. I have no idea what causes your problems, but if you want to look at some of my configuration I''d be glad to. - OJ
On 31-05-13 11:31, Ole Johan Væringstad wrote:> On Mon, May 20, 2013 at 11:23 AM, Arjen <arjenvanweelden@gmail.com> wrote: >> Hi, >> >> I accidentally reproduce my audio passthrough problem in KVM and discovered >> a work-around for Xen. When I boot dom0 with pciback.hide=(00:1b.0), the >> passthrough appears to work but the sound playback is choppy and noisy. >> >> Instead, I let the snd_hda_intel driver load and own the 00:1b.0 device >> during the boot of dom0. After starting dom0 I do a >> xl pci-assignable-add 00:1b.0, which unloads the snd_hda_intel driver, >> before starting the domU with PCI passthrough. Apparently, some kind of >> initialization by the dom0 (or KVM host) is necessary for smooth audio >> playback in the domU. >> >> I don''t know how this fixes my problem, but I hope this work-around might be >> useful for others with similar sound issues. >> >> kind regards, Arjen >> > Arjen > > I have got my setup up and running, passing through an Intel C600/X79 > HDAC to a Gentoo HVM guest. It works fine with hiding from the kernel, > no workarounds needed. I have no idea what causes your problems, but > if you want to look at some of my configuration I''d be glad to. > > - OJ >Hi, It might help me (and possibly others) if you could send your /etc/defaults/grub, kernel .config, and the guest xl configuration file. As this problem happens on two different virtualization systems, I fear that this work-around is required for my particular set-up. Then again, as I appear to be the only one suffering from this, your files might help me fix my configuration. thanks in advance, Arjen