qemu discuss - May 2008 - SoundBlaster 16 removal impending

(Reply directly, as I''m not subscribed here.)

As you may have seen, ARC recently approved my case to remove the 
ancient sbpro driver Solaris.

I''m intent on doing that, because it really helps with our OSS 
integration effort, which I''m now leading.

The problem is, will this impact qemu?  I''m not sure of the answer.  I 
*think* qemu emulates an older ESS1370 device, which is not supported 
(we *do* have a driver for the ESS 1371 though!)  I notice that Virtual 
Box also has support for AC''97 hardware.  Can qemu emulate
AC''97 hardware?

If there is someone in the community that would like to coordinate with 
me (not everyone please!) to ensure that qemu works with our OSS effort, 
and isn''t unduly impacted by the removal of the sbpro driver, please
let
me know.

    - Garrett

Garrett wrote:

(added CC: to xen-discuss@opensolaris.org)
> (Reply directly, as I''m not subscribed here.)
> 
> As you may have seen, ARC recently approved my case to remove the 
> ancient sbpro driver Solaris.
> 
> I''m intent on doing that, because it really helps with our OSS 
> integration effort, which I''m now leading.
> 
> The problem is, will this impact qemu?  I''m not sure of the
answer.
It seems so; "Creative Sound Blaster 16" is one of the emulated
hardware devices offered by qemu.  Note that xVM/xen is using more or
less the same qemu bits for emulating hardware in hvm domains (xen''s
qemu-dm process), so it seems xVM will be affected just like qemu is.

See 
http://xenbits.xensource.com/xen-unstable.hg?file/f681c4de91fc/tools/ioemu/vl.c
~ line 6879, the struct soundhw soundhw[] array for a list of (xVM/xen)
supported audio hardware devices.


> I *think* qemu emulates an older ESS1370 device, which is not supported 
Yep.
> (we *do* have a driver for the ESS 1371 though!) 
> I notice that Virtual 
> Box also has support for AC''97 hardware.  Can qemu emulate
AC''97 hardware?
AC''97 isn''t the big problem when supporting audio in a system
that has "AC''97"
style audio.  It''s the type of audio codec controller chip interfacing
to the
AC''97 codec that matters.  Common AC''97 codec controller chips
are
(older) Intel ICH chipsets (and compatible chipsets from nVidia / AMD), 
VIA chipsets, older ATI chipsets, SoundBlaster audigy, ...

Each one requires a different "AC''97" audio driver.


AFAICT, VirtualBox 1.6 supports emulating some "SoundBlaster 16"
hardware
(not sure if that is the old ISA style card or the newer SoundBlaster 16 PCI;
); might be supported by sbpro(7D).
And it supports "ICH AC97"; which should be supported by
Solaris''
audio810(7D) driver.

> If there is someone in the community that would like to coordinate with 
> me (not everyone please!) to ensure that qemu works with our OSS effort, 
> and isn''t unduly impacted by the removal of the sbpro driver,
please let
> me know.

A few notes:

1) It was my understanding that xen did not emulate sound hardware, and 
that sound was not supported in domU.  Am I mistaken here?   (Notably, 
if we want/need sound, we should try to update Xen to something more 
modern than SB16!  An emulation based on either ESS 1371 or Intel ICH 
would be far far preferable.)

2) Yes, I understand the difference between AC''97 and ICH.  I know that
VirtualBox can emulate ICH sound.  If qemu can be made to emulate the 
same, then it will probably ensure that qemu will have good sound 
support from many OS'' going forward.  (Only a few really old operating 
systems fail to support ICH audio -- think Windows 95 and the earliest 
version of Windows 98.   Those older systems could support either 
AudioPCI128 -- ESS1371 -- or ancient SB16/sbpro.)  If qemu could lift 
the ICH support from VirtualBox, so much the better. :-)

    -- Garrett


Juergen Keil wrote:
> Garrett wrote:
>
> (added CC: to xen-discuss@opensolaris.org)
>
>   
>> (Reply directly, as I''m not subscribed here.)
>>
>> As you may have seen, ARC recently approved my case to remove the 
>> ancient sbpro driver Solaris.
>>
>> I''m intent on doing that, because it really helps with our OSS
>> integration effort, which I''m now leading.
>>
>> The problem is, will this impact qemu?  I''m not sure of the
answer.
>>     
>
> It seems so; "Creative Sound Blaster 16" is one of the emulated
> hardware devices offered by qemu.  Note that xVM/xen is using more or
> less the same qemu bits for emulating hardware in hvm domains
(xen''s
> qemu-dm process), so it seems xVM will be affected just like qemu is.
>
> See 
>
http://xenbits.xensource.com/xen-unstable.hg?file/f681c4de91fc/tools/ioemu/vl.c
> ~ line 6879, the struct soundhw soundhw[] array for a list of (xVM/xen)
> supported audio hardware devices.
>
>
>
>   
>> I *think* qemu emulates an older ESS1370 device, which is not supported
>>     
> Yep.
>
>   
>> (we *do* have a driver for the ESS 1371 though!) 
>> I notice that Virtual 
>> Box also has support for AC''97 hardware.  Can qemu emulate
AC''97 hardware?
>>     
>
> AC''97 isn''t the big problem when supporting audio in a
system that has "AC''97"
> style audio.  It''s the type of audio codec controller chip
interfacing to the
> AC''97 codec that matters.  Common AC''97 codec controller
chips are
> (older) Intel ICH chipsets (and compatible chipsets from nVidia / AMD), 
> VIA chipsets, older ATI chipsets, SoundBlaster audigy, ...
>
> Each one requires a different "AC''97" audio driver.
>
>
> AFAICT, VirtualBox 1.6 supports emulating some "SoundBlaster 16"
hardware
> (not sure if that is the old ISA style card or the newer SoundBlaster 16
PCI;
> ); might be supported by sbpro(7D).
> And it supports "ICH AC97"; which should be supported by
Solaris''
> audio810(7D) driver.
>
>
>   
>> If there is someone in the community that would like to coordinate with
>> me (not everyone please!) to ensure that qemu works with our OSS
effort,
>> and isn''t unduly impacted by the removal of the sbpro driver,
please let
>> me know.
>>     
>
>

> A few notes:
...
> 2) Yes, I understand the difference between AC''97 and
> ICH.  I know that 
> VirtualBox can emulate ICH sound.  If qemu can be
> made to emulate the 
> same, then it will probably ensure that qemu will
> have good sound 
> support from many OS'' going forward.  (Only a few
> really old operating 
> systems fail to support ICH audio -- think Windows 95
> and the earliest 
> version of Windows 98.   Those older systems could
> support either 
> AudioPCI128 -- ESS1371 -- or ancient SB16/sbpro.)  If
> qemu could lift 
> the ICH support from VirtualBox, so much the better.
> :-)
Windows 95/98 don''t need to worry about it, being the guest operating
system they can run with sbpro support surely, or does qemu rely on the sbpro
driver to provide the backend?
--
This message posted from opensolaris.org

Garrett D''Amore wrote:
> A few notes:
> 
> 1) It was my understanding that xen did not emulate sound hardware, and 
> that sound was not supported in domU.  Am I mistaken here?
In a pv domU there is no sound support.

But in a hvm domU using SDL for graphics you can have emulated sound
hardware.  I tested it with a Windows 2000 hvm domU (and a SXCE
hvm domU), using soundhw=''es1370'' in the domain''s
config file.

> (Notably, 
> if we want/need sound, we should try to update Xen to something more 
> modern than SB16!  An emulation based on either ESS 1371 or Intel ICH 
> would be far far preferable.)
Neither ESS 1371 or Intel ICH emulation is available at this time.

Apparently the xen/qemu emulated SB16 card is for an ISA card.
Not sure if it supports ISA PnP;  but current SXCE bits apparently
do not have a device node for the SB16 sound hardware, so sbpro doesn''t
attach.


And the PCI ESS 1370 hardware doesn''t have a SXCE audio driver - but
using my audio1371 driver (which supports 1370, too) I was able to
use audioplay from a Solaris hvm domU.

> 2) Yes, I understand the difference between AC''97 and ICH.  I know
that
> VirtualBox can emulate ICH sound.  If qemu can be made to emulate the 
> same, then it will probably ensure that qemu will have good sound 
> support from many OS'' going forward.  (Only a few really old
operating
> systems fail to support ICH audio -- think Windows 95 and the earliest 
> version of Windows 98.   Those older systems could support either 
> AudioPCI128 -- ESS1371 -- or ancient SB16/sbpro.)  If qemu could lift 
> the ICH support from VirtualBox, so much the better. :-)
> 
>     -- Garrett
> 
> 
> Juergen Keil wrote:
> > Garrett wrote:
> >
> > (added CC: to xen-discuss@opensolaris.org)
> >
> >   
> >> (Reply directly, as I''m not subscribed here.)
> >>
> >> As you may have seen, ARC recently approved my case to remove the 
> >> ancient sbpro driver Solaris.
> >>
> >> I''m intent on doing that, because it really helps with
our OSS
> >> integration effort, which I''m now leading.
> >>
> >> The problem is, will this impact qemu?  I''m not sure of
the answer.
> >>     
> >
> > It seems so; "Creative Sound Blaster 16" is one of the
emulated
> > hardware devices offered by qemu.  Note that xVM/xen is using more or
> > less the same qemu bits for emulating hardware in hvm domains
(xen''s
> > qemu-dm process), so it seems xVM will be affected just like qemu is.
> >
> > See 
> > 
http://xenbits.xensource.com/xen-unstable.hg?file/f681c4de91fc/tools/ioemu/vl.c
> > ~ line 6879, the struct soundhw soundhw[] array for a list of
(xVM/xen)
> > supported audio hardware devices.
> >
> >
> >
> >   
> >> I *think* qemu emulates an older ESS1370 device, which is not
supported
> >>     
> > Yep.
> >
> >   
> >> (we *do* have a driver for the ESS 1371 though!) 
> >> I notice that Virtual 
> >> Box also has support for AC''97 hardware.  Can qemu
emulate AC''97 hardware?
> >>     
> >
> > AC''97 isn''t the big problem when supporting audio in
a system that has
"AC''97"
> > style audio.  It''s the type of audio codec controller chip
interfacing to
the
> > AC''97 codec that matters.  Common AC''97 codec
controller chips are
> > (older) Intel ICH chipsets (and compatible chipsets from nVidia /
AMD),
> > VIA chipsets, older ATI chipsets, SoundBlaster audigy, ...
> >
> > Each one requires a different "AC''97" audio driver.
> >
> >
> > AFAICT, VirtualBox 1.6 supports emulating some "SoundBlaster
16" hardware
> > (not sure if that is the old ISA style card or the newer SoundBlaster
16
PCI;
> > ); might be supported by sbpro(7D).
> > And it supports "ICH AC97"; which should be supported by
Solaris''
> > audio810(7D) driver.
> >
> >
> >   
> >> If there is someone in the community that would like to coordinate
with
> >> me (not everyone please!) to ensure that qemu works with our OSS
effort,
> >> and isn''t unduly impacted by the removal of the sbpro
driver, please let
> >> me know.
> >>     
> >
> >   
>

Juergen Keil wrote:
> Garrett D''Amore wrote:
>
>   
>> A few notes:
>>
>> 1) It was my understanding that xen did not emulate sound hardware, and
>> that sound was not supported in domU.  Am I mistaken here?
>>     
>
> In a pv domU there is no sound support.
>
> But in a hvm domU using SDL for graphics you can have emulated sound
> hardware.  I tested it with a Windows 2000 hvm domU (and a SXCE
> hvm domU), using soundhw=''es1370'' in the
domain''s config file.
>   
Ah, OK.  Didn''t realize the differences here between pv and hvm.   
Thanks for clearing that up.
>
>   
>> (Notably, 
>> if we want/need sound, we should try to update Xen to something more 
>> modern than SB16!  An emulation based on either ESS 1371 or Intel ICH 
>> would be far far preferable.)
>>     
>
> Neither ESS 1371 or Intel ICH emulation is available at this time.
>
> Apparently the xen/qemu emulated SB16 card is for an ISA card.
> Not sure if it supports ISA PnP;  but current SXCE bits apparently
> do not have a device node for the SB16 sound hardware, so sbpro
doesn''t
> attach.
>   
Ah, so the *removal* actually doesn''t represent a loss of functionality
for Xen.  So at least on that front, we''re good to go.
>
> And the PCI ESS 1370 hardware doesn''t have a SXCE audio driver -
but
> using my audio1371 driver (which supports 1370, too) I was able to
> use audioplay from a Solaris hvm domU.
>   
Right.  We may be fixing that, if there is a need.  It certainly sounds 
like there might be.

Do you have your own audio1371 driver?  Is it a SADA driver?

    -- Garrett
>
>   
>> 2) Yes, I understand the difference between AC''97 and ICH.  I
know that
>> VirtualBox can emulate ICH sound.  If qemu can be made to emulate the 
>> same, then it will probably ensure that qemu will have good sound 
>> support from many OS'' going forward.  (Only a few really old
operating
>> systems fail to support ICH audio -- think Windows 95 and the earliest 
>> version of Windows 98.   Those older systems could support either 
>> AudioPCI128 -- ESS1371 -- or ancient SB16/sbpro.)  If qemu could lift 
>> the ICH support from VirtualBox, so much the better. :-)
>>
>>     -- Garrett
>>
>>
>> Juergen Keil wrote:
>>     
>>> Garrett wrote:
>>>
>>> (added CC: to xen-discuss@opensolaris.org)
>>>
>>>   
>>>       
>>>> (Reply directly, as I''m not subscribed here.)
>>>>
>>>> As you may have seen, ARC recently approved my case to remove
the
>>>> ancient sbpro driver Solaris.
>>>>
>>>> I''m intent on doing that, because it really helps with
our OSS
>>>> integration effort, which I''m now leading.
>>>>
>>>> The problem is, will this impact qemu?  I''m not sure
of the answer.
>>>>     
>>>>         
>>> It seems so; "Creative Sound Blaster 16" is one of the
emulated
>>> hardware devices offered by qemu.  Note that xVM/xen is using more
or
>>> less the same qemu bits for emulating hardware in hvm domains
(xen''s
>>> qemu-dm process), so it seems xVM will be affected just like qemu
is.
>>>
>>> See 
>>>
>>>       
>
http://xenbits.xensource.com/xen-unstable.hg?file/f681c4de91fc/tools/ioemu/vl.c
>   
>>> ~ line 6879, the struct soundhw soundhw[] array for a list of
(xVM/xen)
>>> supported audio hardware devices.
>>>
>>>
>>>
>>>   
>>>       
>>>> I *think* qemu emulates an older ESS1370 device, which is not
supported
>>>>     
>>>>         
>>> Yep.
>>>
>>>   
>>>       
>>>> (we *do* have a driver for the ESS 1371 though!) 
>>>> I notice that Virtual 
>>>> Box also has support for AC''97 hardware.  Can qemu
emulate AC''97 hardware?
>>>>     
>>>>         
>>> AC''97 isn''t the big problem when supporting audio
in a system that has
>>>       
> "AC''97"
>   
>>> style audio.  It''s the type of audio codec controller chip
interfacing to
>>>       
> the
>   
>>> AC''97 codec that matters.  Common AC''97 codec
controller chips are
>>> (older) Intel ICH chipsets (and compatible chipsets from nVidia /
AMD),
>>> VIA chipsets, older ATI chipsets, SoundBlaster audigy, ...
>>>
>>> Each one requires a different "AC''97" audio
driver.
>>>
>>>
>>> AFAICT, VirtualBox 1.6 supports emulating some "SoundBlaster
16" hardware
>>> (not sure if that is the old ISA style card or the newer
SoundBlaster 16
>>>       
> PCI;
>   
>>> ); might be supported by sbpro(7D).
>>> And it supports "ICH AC97"; which should be supported by
Solaris''
>>> audio810(7D) driver.
>>>
>>>
>>>   
>>>       
>>>> If there is someone in the community that would like to
coordinate with
>>>> me (not everyone please!) to ensure that qemu works with our
OSS effort,
>>>> and isn''t unduly impacted by the removal of the sbpro
driver, please let
>>>> me know.
>>>>     
>>>>         
>>>   
>>>       
>
>

Garrett D''Amore wrote:
> Juergen Keil wrote:
> > Garrett D''Amore wrote:
> >
> >   
> >> A few notes:
> >>
> >> 1) It was my understanding that xen did not emulate sound
hardware, and
> >> that sound was not supported in domU.  Am I mistaken here?
> >>     
> >
> > In a pv domU there is no sound support.
> >
> > But in a hvm domU using SDL for graphics you can have emulated sound
> > hardware.  I tested it with a Windows 2000 hvm domU (and a SXCE
> > hvm domU), using soundhw=''es1370'' in the
domain''s config file.
> >   
> 
> Ah, OK.  Didn''t realize the differences here between pv and hvm.
> Thanks for clearing that up.
hvm is the one that emulates PC hardware / devices. A hvm domain
doesn''t need a special OS modified for use with xen (so you can
install a standard copy of Windows (or Solaris, Linux, ...) in a 
hvm domain.

In a pv domain you have to use an OS that has been modified to run under
control of the xen hypervisor (like Linux, Solaris, xxxBSD - but not
Windows).


> >> (Notably, 
> >> if we want/need sound, we should try to update Xen to something
more
> >> modern than SB16!  An emulation based on either ESS 1371 or Intel
ICH
> >> would be far far preferable.)
> >>     
> >
> > Neither ESS 1371 or Intel ICH emulation is available at this time.
> >
> > Apparently the xen/qemu emulated SB16 card is for an ISA card.
> > Not sure if it supports ISA PnP;  but current SXCE bits apparently
> > do not have a device node for the SB16 sound hardware, so sbpro
doesn''t
> > attach.
> >   
> Ah, so the *removal* actually doesn''t represent a loss of
functionality
> for Xen.  So at least on that front, we''re good to go.
Yep.


Well, maybe the old boot.bin / DCA based Solaris releases are
able to find the ISA SB16 card, but last time I tried it,  the old DCA
based Solaris releases needed > 60 minutes from starting boot.bin until
the Solaris kernel gets loaded.  Some details can be found here:

   http://opensolaris.org/jive/thread.jspa?threadID=36498&tstart=210


So I doubt anyone will run old Solaris releases (<= S10 x86 FCS) under xen.

> > And the PCI ESS 1370 hardware doesn''t have a SXCE audio
driver - but
> > using my audio1371 driver (which supports 1370, too) I was able to
> > use audioplay from a Solaris hvm domU.
> >   
> 
> Right.  We may be fixing that, if there is a need.  It certainly sounds 
> like there might be.
> 
> Do you have your own audio1371 driver? 
Yes, http://www.tools.de/opensource/solaris/audio/

> Is it a SADA driver?
It offers the standard SADA compatible interfaces (with the exception of
mixer mode).