Mednafen Members Members   Search Search   Help Help   Register Register   Login Login   Home Home
Home » Mednafen » Development » Mednafen 0.8.D Release Candidate 1
Show: Today's Messages  :: Show Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
Mednafen 0.8.D Release Candidate 1 [message #1606] Tue, 29 December 2009 23:27 Go to next message
Administrator  [PM]
If anyone running FreeBSD, NetBSD, OpenBSD, and/or Solaris could test this and make sure it compiles ok, and more to the point, that the sound is ok, and report your findings in this topic, it would be appreciated.

If anyone running ALSA/OSS with Linux could do the sound testing as well, it would be appreciated too.

If you can, specify the sound card and driver(ALSA/OSS-free/OSSv4/etc) you're using. (Linux ALSA users can cat /proc/asound/modules).

Changes since 0.8.C:
        Lynx:  Fixed a bug in the cart loader code that would cause a crash if the ROM bank size was larger than the actual data available in the
        file(as is the case with some homebrew programs).  Thanks to "Wookie" for the patch.

        Build files were regenerated using autoconf 2.64 and aclocal 1.11(previously, they were generated with autoconf 2.61 and aclocal 1.10.1).

        Fixed a crashing problem when entering an invalid menu choice("0") in the cheat interface.  Thanks to
        tsenart for reporting the bug.

        GB:  The GameBoy module now respects the "filesys.disablesavegz" setting in respect to saved
        battery-backed RAM.

        Added support for "lurkers" on the network play server.  Previous versions of Mednafen don't lack support for this per se, but there
        would be cosmetic issues with status messages printed to the internal console.

        SexyAL:  Fixed a bug affecting the return value from RawCanWrite() in the ALSA driver.  The returned value was typically too
                 small by a factor of 4.  The effects of this bug included potential long periods of garbled sound
                 during netplay.

                 Fixed the return value from RawCanWrite() in the JACK driver.  It was being clamped to a value
                 that was too small by a factor of 4; however, the clamp value was already excessively large in a way
                 that this bug would should have only been triggered if the "soundbufsize" setting was excessively large.
                 The effects of this bug would be similar to the ALSA RawCanWrite() bug.

                 The ALSA and OSS drivers will now try to set audio output to 2 channels if the source data only has 1 channel, and 16-bit signed if the
                 source data is 8-bit(automatic conversion is done).  This is done to allow for lower period/fragment sizes, as, in ALSA's internals at least,
                 the minimum period sizes are expressed in bytes, not sound frames.

                 The ALSA and OSS drivers will now try to set lower period/fragment sizes than previous versions of Mednafen did.  With default settings, for
                 ALSA, the new period/fragment size is 50% of what it was before, and for OSS, 25%.  Also, there's a new setting to override
                 the SexyAL's driver's preferred period/fragment sizes, named "sound.period_time"(default value of 0: no override).
                 The period/fragment size is expressed in microseconds.  If the new, lower fragment sizes cause problems, the setting can be changed to "2666"
                 to approximate the fragment size selection in previous versions of Mednafen when using ALSA output, and "5333" when using OSS output.

                 Added a workaround to the OSS driver for a bug in ALSA(and hence, ALSA's in-kernel OSS emulation) that could cause the emulator to run far
                 too fast for a short period of time if a buffer underflow occurred.

                 The ALSA's driver's RawCanWrite() method now(finally) uses snd_pcm_avail_update() instead of snd_pcm_delay().
                 This should improve performance and frameskipping behavior when the ALSA output is not routed directly to a physical device, such as the case with
                 PulseAudio(though PulseAudio is still not recommended :b).

[Updated on: Fri, 14 November 2014 21:49]

Re: Mednafen 0.8.D Release Candidate 1 [message #1607 is a reply to message #1606 ] Tue, 29 December 2009 23:32 Go to previous messageGo to next message
Administrator  [PM]
I'll be uploading a Mednafen-Server alpha/beta/RC/meowcat version within a week or two once I work out a few issues, that will let more users connect to a single game instance than there are virtual controllers available(and eventually allow for cooperative/sharing playing with single-player portable games).

[Updated on: Tue, 29 December 2009 23:32]

Re: Mednafen 0.8.D Release Candidate 1 [message #1608 is a reply to message #1606 ] Fri, 01 January 2010 12:07 Go to previous messageGo to next message
bzt1  [PM]
Nice to see Mednafen being updated. Thanks for your continuing work. I will report problems with ALSA and general ones too wherever I can.

EDIT: Just wanted to add it compiles fine on Ubuntu 9.10 64 bit.

[Updated on: Fri, 01 January 2010 12:52]

Re: Mednafen 0.8.D Release Candidate 1 [message #1609 is a reply to message #1606 ] Fri, 01 January 2010 12:41 Go to previous messageGo to next message
bzt1  [PM]
Actually, I think I already have something to report.

A while ago, I installed the new version of Ubuntu which unfortunately comes with the messy PulseAudio. As a means to get a perfect sound experience on my machine, I uninstalled it to use ALSA only. Then there still was a problem with Mednafen occupying the sound cart. This can be fixed using "sexyal-literal-default" as the sound device but it comes at a cost that I just found out.

All games feel choppy during play as if a frameskipping option has been enabled. Revering to "default" audio device gets rid of the performance problem, of course also reverting to the problem mentioned above. This applies to Mednafen 0.8.C as well as this RC.

This is the output of cat /proc/asound/modules:
 0 snd_ca0106


Greetz, bzt
Re: Mednafen 0.8.D Release Candidate 1 [message #1610 is a reply to message #1606 ] Sat, 02 January 2010 00:25 Go to previous messageGo to next message
Administrator  [PM]
Have you tried OSSv4? It hasn't worked well with the old/exotic/USB sound cards I've tried it with, but some people swear by it.

Looking at ALSA's driver for your sound card, it looks like it has rather mediocre buffer capabilities. Otherwise, I was going to suggest a few .asoundrc rules.

If you have a little money to spend, you could get a sound card with hardware mixing:
http://www.alsa-project.org/main/index.php/Special:Search?search=hwmix&fulltext=Search

Personally, I've used the Turtle Beach AU8820/AU8830 cards with success(frequency response wasn't as good as I would have liked, but it was decent), as well as the Echo Mia, and the CS46xx-using Turtle Beach Santa Cruz. CS46xx is nice hardware, but the ALSA driver for it is a little buggy sometimes, and OSSv4 doesn't work with it(at least, not my Santa Cruz). Echo Mia has very good sound quality, but its hardware mixing doesn't support multiple streams with different sample rates, so it's kind of tricky setting up .asoundrc correctly and configuring your applications, though it works well once you do. Echo Mia isn't supported by OSSv4 at all, and it's also rather expensive. (I got my AU8830 card and my CS46xx card for each less than $10)

I could work around large period sizes in Mednafen's ALSA code, but I would need to think about it a bit, so it's not going to be in 0.8.D. Wink
And, I really don't like spending lots of time fixing something that IMO should be addressed in ALSA itself.

[Updated on: Sat, 02 January 2010 00:26]

Re: Mednafen 0.8.D Release Candidate 1 [message #1611 is a reply to message #1606 ] Sat, 02 January 2010 02:44 Go to previous messageGo to next message
Administrator  [PM]
I was able to get OSSv4 to work with my motherboard's onboard audio. If you go that route, after installing, edit "/usr/lib/oss/conf/osscore.conf", and set max_intrate to at least 1000(the default is 100), 2000 is probably safe too, unless you're on an older system with a slow CPU.

It should look like so:

# internal clock rate (HZ) may not make any actual improvement.
#
# Some devices use fixed fragment size and this parameter will not have any
# effect with them. For example the Digi32 and Digi96 devices work in this way.
# 
max_intrate=1000


...and then run "sounoff" and then "soundon".

[Updated on: Sat, 02 January 2010 02:46]

Re: Mednafen 0.8.D Release Candidate 1 [message #1612 is a reply to message #1606 ] Sat, 02 January 2010 04:51 Go to previous messageGo to next message
bzt1  [PM]
Thanks for your suggestions. I tried installing OSS with relatively few luck (read: patience). Messing around with the .asoundrc resulted that Mednafen works fine with a buffer size of 1024 but this negatively affects the sound quality of some other applications, especially Wine.

My sound cart may be a bit aged, in fact it is the oldest part of my recently bought machine. I continued to use it because it still does its task good. Once the need arises, I will certainly go for a sound cart with hardware mixing capabilities. For now I think I will go with the exclusive sound route.

Greetz, bzt
Re: Mednafen 0.8.D Release Candidate 1 [message #1613 is a reply to message #1606 ] Sat, 02 January 2010 13:10 Go to previous messageGo to next message
zombie_ryushu  [PM]
And... has support been added for any new platforms? What about GameBoy Colorization via the GameBoy Color Bios?
Re: Mednafen 0.8.D Release Candidate 1 [message #1619 is a reply to message #1606 ] Thu, 21 January 2010 13:44 Go to previous messageGo to next message
delt  [PM]
Just compiled this version (0.8.D-rc1)
Using linux 2.6.31.1 on a toshiba satellite 2410 laptop. Sound hardware is a shitty ac97 chip that is supported by the snd-intel8x0 driver.

Sound bugs still present from 0.8.C: (tested mostly with nes and gba emulation)

Crackling in the audio, even with large buffer sizes.
Sound rate is stuck at maximum value (48KHz), flag -soundrate [x] on command line is ignored unless an out-of-range value is given (in which case the emulator doesn't start, as expected)

Same with 0.8.C and this version, though sound in 0.8.C had less popping/crackling when using oss (alsa's oss-emulation). I don't think any of these are related to the sound drivers, because other programs work OK.


---
Re: Mednafen 0.8.D Release Candidate 1 [message #1620 is a reply to message #1606 ] Thu, 21 January 2010 20:49 Go to previous messageGo to next message
Administrator  [PM]
If I had to guess, your sound device or the driver for it is bugging out on small period sizes.

Try passing -sound.period_time 10666
to Mednafen and see if the problem goes away. If it does, you might want to file a bug report with your distribution or with ALSA developers...
Re: Mednafen 0.8.D Release Candidate 1 [message #1642 is a reply to message #1619 ] Tue, 02 March 2010 13:48 Go to previous messageGo to next message
delt  [PM]
That fixed it, thanks.


---
icon6.gif  Re: Mednafen 0.8.D Release Candidate 1 [message #1650 is a reply to message #1606 ] Mon, 22 March 2010 07:01 Go to previous messageGo to next message
lewellyn  [PM]
As you've requested, it's had some preliminary testing on (Open)Solaris. Smile Here is the spec file.

Note that I couldn't get WonderSwan to work, and I had to patch around a couple of things. Also, all I've tested so far was NES.
Re: Mednafen 0.8.D Release Candidate 1 [message #1651 is a reply to message #1606 ] Mon, 22 March 2010 11:14 Go to previous messageGo to next message
Administrator  [PM]
Have you tried adding

#ifdef CS
#undef CS
#endif

to the top of src/wswan/debug.h to see if that fixes the compilation issue?
Re: Mednafen 0.8.D Release Candidate 1 [message #1652 is a reply to message #1606 ] Mon, 22 March 2010 21:49 Go to previous messageGo to next message
Near  [PM]
Protip: you can #undef without #ifdef first, won't throw any warnings or errors Smile
icon14.gif  Re: Mednafen 0.8.D Release Candidate 1 [message #1653 is a reply to message #1651 ] Tue, 23 March 2010 03:43 Go to previous messageGo to next message
lewellyn  [PM]
Thanks. That got me on the right track. I eventually just threw in the towel last night, since it took me a number of hours to get everything aside from WonderSwan going. Very Happy

This build seems to be missing sound support for some reason, but that may be any number of causes. (Many not Mednafen-related...)

NES still works fine; haven't had time to test anything else. I'll stick a note on my site and see if there's any feedback...

Hopefully when 0.8.D is released, I can get Mednafen into the OpenSolaris contrib repository. (Unless you want me to stick the RC versions in there once the SFE version gets some testing... Of course, I'll need input on a better numbering system than I'm using right now for the RCs. Smile )

(Note that the URL I gave in the previous post is going to remain valid as long as Mednafen doesn't change names and lives in SFE.)
Re: Mednafen 0.8.D Release Candidate 1 [message #1658 is a reply to message #1652 ] Wed, 31 March 2010 21:07 Go to previous message
safaribans  [PM]
Works really beautifully with ALSA on Debian Squeeze (x86). However, if alsa is tied up, and I use sexy literal, things get laggy due to default period size (1024), and if I lower the period size in dmix.conf it messes up gnash and audacious. So I'll definitely just stick to the default.


cat /proc/asound/modules
0 snd_hda_intel


-----------
Works excellently with emulated systems too, the sound is just beautiful.

mednafen is a standard install on all the Linux boxes I maintain. I'd like to see a nice deb package some day bundled with some public domain roms, so people can get an idea from the start about how great this emu is in terms of consistency and features.

[Updated on: Sun, 18 April 2010 03:27]


I have never let my schooling interfere with my education.
-- Mark Twain
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic:PC Engine lockups.
Next Topic:How to contribute?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ ]

Current Time: Thu Mar 28 18:58:04 CDT 2024
.:: Contact :: Home ::.

Powered by FUDforum.
Copyright © FUDforum Bulletin Board Software