summaryrefslogtreecommitdiff
path: root/s390.ld
diff options
context:
space:
mode:
authormalc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>2008-06-08 01:07:48 +0000
committermalc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>2008-06-08 01:07:48 +0000
commit2c44375d649910677dd9cdcf170f4dbaafa3f193 (patch)
treed2db679af92b263e9c6d81b071a8ad2b7f2687df /s390.ld
parentd865bab55244797cce4f67a2a8196cbb0ceabc47 (diff)
downloadqemu-2c44375d649910677dd9cdcf170f4dbaafa3f193.tar.gz
qemu-2c44375d649910677dd9cdcf170f4dbaafa3f193.tar.bz2
qemu-2c44375d649910677dd9cdcf170f4dbaafa3f193.zip
Do not scare users with ominous error messages from AUD_open*
Apparently Windows Server 2003 sets the frequency for either mc or pi voice to zero, which in turn triggers a call to audio_bug from this chain: open_voice -> AUD_open_in -> audio_bug (audio_validate_settings): A bug was just triggered in AUD_open_in ... Context: audio: frequency=0 nchannels=2 fmt=S16 endianness=little But since no attempt by the said OS is made to actually use the voice with zero frequency this can be considered normal behavior. Hence if zero freqency situation is encountered - close current voice, and make noises if the guest tries to use it. Reported by simon@...ve git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@4694 c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 's390.ld')
0 files changed, 0 insertions, 0 deletions