#229 Auto-set the samples setting to have best quality

open
nobody
None
5
2011-09-04
2011-09-04
No

this info may be helpful to fine-tune openmsx sound automagically at runtime.

'set samples 4096' helped to obtain an acceptable sound.

i can provide any further info about my system setup.

some useless details are below.

***

lsb_release -d
Description: Ubuntu 10.04.3 LTS
Ok

on my architecture (athlon64), top was showing with default openmsx settings:
(14:46:02) buguldey1: Xorg 25% cpu
(14:46:02) buguldey1: openmsx 18%
(14:46:03) buguldey1: pulseaudio 6%
(14:46:03) buguldey1: top 2%
(14:46:03) buguldey1: skype 2% (while being idle, only supporting the net connection)
(14:46:03) buguldey1: all other apps: 0%
(14:46:03) buguldey1: 25+18+6=49%

set samples gave 1024. set samples 4096 helped to obtain an acceptable sound.

Discussion

  • Anonymous - 2011-09-04

    1. openmsx could inspect the system (at OS bootup and/or on openmsx launch) and fine-tune settings.
    2. at set samples 1024 (the default i had) the sound was stittering.
    3. set samples 2048 did not help, the sound was still stittering.

     
  • Anonymous - 2011-09-04
    • summary: this may be helpful to fine-tune sound automagically --> stitter. this may be helpful to fine-tune sound automagicly
     
  • Manuel Bilderbeek

    • labels: 420820 -->
    • summary: stitter. this may be helpful to fine-tune sound automagicly --> Auto-set the samples setting to have best quality
     
  • Manuel Bilderbeek

    Basically, your request is to let openMSX find a good way for the samples setting.

    I'll change this bug report into just that. But I don't think it's easy or even possible to do so. I'll let Wouter comment on that.

    The issue is that this setting is different for everyone, for some reason... See also the FAQ.

     
  • Anonymous - 2011-09-05

    I guess this ticket is highly complex to do appropriately.

     
  • Wouter Vermaelen

    Indeed, it's very hard to automatically come up with a good value for the 'samples' setting.

    Preferably you set this value as low as possible to also get a lower latency for the sound output (IIRC on OSX you could easily set this value to 512 or even 256). OTOH on some systems you need to give this setting a fairly high value to get decent audio quality.

    Personally I had to change this setting from 1024 (the default) to 2048 after I started using pulseaudio, Though the increased latency is a bit annoying.

    It may also help to, instead of changing the 'samples' value, switch to a different openMSX sound driver (e.g. 'set sound_driver libao', OTOH libao still has problems with 'throttle=off'. On windows systems the 'DirectX' sound driver generally works best). It might be possible some of these problems will be solved by using ALSA instead of SDL (or libao) in the sound driver. Any volunteers to write such a driver?

    On 2011/08/27 we made some changes to the openMSX sound system. It _might_ be the case that this problem has been improved a little bit by that change, though I don't expect major differences.

     
  • Maarten ter Huurne

    About the "samples" setting: maybe it would make more sense to have an "audio_latency" setting where the user can specify the buffer size in milliseconds. That would make the setting independent of the output frequency for one. Also "100 ms" is more meaningful in my opinion than "4096 samples".

    The libao ALSA driver could be used as an example for an ALSA driver in openMSX itself. There wouldn't be an immediate advantage, but it would give much finer control of audio playing and therefore allow experiments that might eventually lead to a driver that has both low latency and few stutters.

     
  • Anonymous - 2011-09-06

    > set sound_driver libao

    both openmsx 0.8.1 console and manual show 'none' & 'sdl' as the only sound_driver values...

     
  • Maarten ter Huurne

    That is correct: the libao sound driver was added after 0.8.1 was released.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks