Sounds like you don't have enough memory. The Windows API probably precaches the whole mp3 (I'm just guessing), Quakespasm's library feeds it to the sound system in chunks.

Either way, I know almost nothing about Windows settings and such, I never change mine. People at superuser.com or Tom's Hardware might know such things. 

quakespasm includes mp3 decoders.
mp3 patents technically violate the gpl and/or patent law.
(another reason for me to not include dependancies with my quakespasm patch).
using the system's mp3 decoders is one way around that issue (avoids distributing it, and system component avoid gpl issues).

markv uses directshow, which is a system component...
but directshow is poo...
that said, even 17 seconds is excessive even for directshow. wth?

the third way is to use windows' 'acm' api, which can provide stream-based mp3 decoding, which is the method that fte uses. this doesn't do anything silly like scanning the entire file, and isn't even aware of the file. yay pk3s.
markv already uses this api! but the other way around (encoding mp3 for avis).
and with it decoding to memory, it can also be used for sound effects too! yay!..
but yeah, directshow sucks. 

According to Google;

the last MP3 decoding patent expired September 2015. (Decoding = playback)

the last MP3 encoding patent expires April, 2017. (Encoding = recording)

Mark V still can play the music from the CD, so you can always put the Quake cd in the CD drive.

Mark V's mp3 playback is plenty fast on the computers I have tried it on and I've not seen anyone else in this thread (1100+ posts) report that it is slow. But I remember Fifth having problems to get it to work on his Surface Pro, then he did a driver update or something and it worked fine. 

I might add that DirectQ always used DirectShow (AFAIK) for mp3 playblack, and I never recalled seeing a "mp3 is slow" thing in a DirectQ thread -- DirectQ got tons of usage too when MH was developing it.

But yeah, I don't know much about Windows settings and drivers and such --- I never change any settings.

You could try playing music from the CD since Mark V still supports that. 

Was it a driver update? I can't remember now, I thought you had fixed it because I moaned incessantly ;) 

I was going to ask you what you did to fix it.

You posted something like "I reinstalled <XYZ> and now my music is working!" 

try uninstalling+reinstalling windows media player. that'll probably reset whatever is screwed. that or it'll fail completely, but hey, there's always ffmpeg+vlc, right? 

I wasn't aware that the ACM library -- which Mark V already uses for other purposes -- could do mp3 playback, which sounds like unlike DirectShow isn't subject to Windows Media Player settings.

So at some point in the future, I may look through FTE and rewire Mark V to do what Spike does, which is more robust.

/But since I have no time for engine coding, that'd be sometime in 2017 

Mixing the music and quake sfx in-engine is somewhat tricky (if you want the final result to match vanilla quake running at -sndspeed 11025 + a CD playing / an external music player).

You need to duplicate what happens in the OS mixer, so running the 11025Hz output of the quake mixer through a high-quality resampler to get 44100Hz, then mixing in the music, taking care to reduce the volume of the resampled sfx a bit to avoid clipping. Resampling after sfx mixing is key to keeping it sounding like vanilla quake.

(the above doesn't apply if for those who play with -sndspeed 44100 which I find ear-grating :P) 

most modern (cheap) sound cards favour 48khz(dvd quality).
apis like wasapi (that thing that directsound is now a wrapper around) tend to favour floating-point audio too (which incidentilly makes clipping MUCH easier to deal with, also, hurrah for sse).
resampling 11khz to 44khz, crapping over it a bit, then resampling to 48khz via directsound is kinda crazy.
especially when that first resample step *STILL* uses nearest sampling...
so yes, I'm not surprised at you finding it ear-grating.

back in the dos days, the lack of os-level mixing meant that taking actual control of the hardware output rate made sense. with quake spitting out 11khz audio and the sound card outputting analog audio smoothly at the same rate, the hardware would then do linear sampling for you. obviously this varies based upon sound chips.
Or in other words, just fix ResampleSfx to use linear resampling instead of nearest, and have quake output to the OS's native mixer rate, and you'll have audio that sounds as close to vanilla quake as you can realistically get.
There is imho no point in lowpass filters etc, unless you're trying to get underwater effects or whatever... which isn't vanilla quake.

and yes, mp3s played at 11khz sound terrible. so don't do that.

side note: it was recently reported to me that the existing method to get FTE to play internet radio stations sucks.
While I was of course aware of this, I really cba to change anything. We have OSS4 now, the dude should just use a real player, they generally have hotkeys anyway. 

Hypothesis: Could the weird delay be caused by Windows Media Player searching for covers and metadata through the Internet?

Does the MP3 delay also happen in windowed mode? Does any icon activity or notification message pop up in the Windows taskbar during that time?

Maybe Windows is showing up one of those system pop-up windows asking for you to confirm something before x seconds, but since you're in fullscreen you can't see it and the game has to wait for the background pop-up window countdown to end before playing the track. 

Real Player? Is that still around?

Oh wait. The dead one is WinAmp ... the one that -- It Really Whips the Llama's Ass. 

My engine instincts are a bit slow and rusty .. but my reinterpretation would be that ACM provides a mp3 decoder and based on what you said --- and I haven't looked at FTE's code --- it throws it into Quake sound mixer's buffer.

I know with SDL2 you have to use a callback for the sound buffer, but AFAIK not another thread ... but Spike may use another thread.

Hence I used the word "maybe". ;-)

When I use the word "maybe", my spidersense has told me there are 2 or 3 wildcards that once I witness I may not feel like is worth the effort, haha.

@mankrip --- he may be on to something! Even for an old computer, 17 seconds sounds weird. 

"I might add that DirectQ always used DirectShow (AFAIK) for mp3 playblack"

I gave DirectQ a try... and I get the exact same result: very close to a 17 second delay to load the MP3 on the Start map.

I do run Quake in a window, and there are no Windows notifications happening. I disabled all the "download media info" stuff in Windows Media Player.

I tried uninstalling (rather, rolling back to version 9 is what it does) my Windows Media Player 11, but running either version seems to make no difference, so I re-installed version 11 again.

I tried running on my much older WinXP laptop, and (although it may have other issues running smoothly) the MP3 loading did not experience much of a delay at all....


So I guess it's just my netbook that's the problem, though I've never had a similar issue with MP3s. I mean, yeah, it's a WinXP netbook, but it should certainly be good enough to play Quake and MP3s (ASUS EeePC, Intel Atom CPU N270 @ 1.60 GHz, 0.99 GB RAM).


Let me do some re-encoding of the MP3 and see what results I get....

Using Track04.mp3 (8:20 length) for Start map, I originally ripped it as stereo, 63 kbps, 22050 Hz. With that I get the pretty consistent 17 second delay when I switch on external music.

Well, now I'm using Audacity to convert the MP3 to different formats, and getting significant results.

Simply re-encoding the file at the same 64 kbps, 22050 Hz, the loading delay drops to about 7 seconds.

I believe I used CDex to rip the tracks from the Quake CD a few years back... maybe it used some weird encoder? Or was 63 kbps a weird rate? Actually, Windows reports the original MP3 is 63 kbps, but VLC says it's 64....

If I drop the quality way down to to 16 kbps, 11025 Hz, it drops the loading time to 2 seconds.

Going up to 128 kbps, 44100 Hz, the load delay goes up to about 14 seconds, which is still better than before.

I guess I just need to decide what quality I want to sacrifice for a decent load time. 5-7 seconds is tolerable, especially compared to that 17.


I guess the issue was some weird combination of my WinXP netbook and the encoding of the MP3s.... Though I will still have a delay, but it will be much less.

Anyway, thanks, everyone, for the information and attempted help.


Hm, oddly, it seems that sometimes encoding at the same parameters will produce different results (like a 10 second delay instead of the usual 6-7), which are consistent with that MP3 until I encode again.... Eh, I'll just have to tinker around with it.

Er, just loading my original MP3 in Winamp and stripping out the ID3v2 tag (which only contained "genre: unknown, track: 4") drops the loading time from the 17 to only 10 seconds.... Doing the same thing with the Audacity re-encoded file (that still held the tag info) makes no difference at all in the loading time.

Eh. Computers are weird!

If anyone else would like to try my weird MP3 file to see if you get any weird delay (you probably won't...) here, have at it! http://fvfonline.com/Track04.mp3 

You might not like this thought but something that occurred to me ...

Windows Media Player might be trying to connect to a long dead web site (for reasons unknown) and it takes 15 seconds for the load to fail.

If you had some sort of network traffic utility that could identify the theoretical dead web site, you might be able to use Google for a similar problem or uses the hosts file to block the DNS and at least make it fail faster.

One thought, possibly wrong ... sorry you have a pointless stupid problem ... 

There's a simpler way to test that � just unplug the network cable and turn off the Wi-Fi device.

After doing so, disabling the antivirus may also help � some antivirus programs does scan any files accessed by supposedly unusual means before allowing the programs to access them.

And lastly, see if there's any music scrobbler (such as Last.FM) installed.

The antivirus is a strong candidate, since encoding methods can make the file harder to go through deep analysis, and antivirus programs usually does some special analysis on ID3 tags to prevent some kinds of exploits (I vaguely remember reading something about security issues with ID3 tags).

Also, players like Winamp and Windows Media Player are likely to be in a list of trusted media players for the antivirus to ignore. Custom Quake engines aren't. 

If this has anything to do with the problem, appears thats Windows Media Player may be trying to find missing meta data using the internet (which probably tries to contact a long dead site ...)

http://www.winvistatips.com/threads/long-delay-between-music-tracks-in-dvd-slideshow.147538/ 

re: resampling algorithms: nearest-neighbour is terrible for audio, but so are linear and cubic. Upsampling 11kHz audio is unforgiving because with the nyquist frequency at 5.5kHz, the distortion let through above 5.5kHz by a poor resampler is right in the sensitive area of human hearing (an ideal upsampler for 11kHz audio is a brickwall lowpass filter at ~5.5kHz).

You got me curious about what kind of filtering vintage cards had, and I turned up this thread: https://www.vogons.org/viewtopic.php?f=32&t=49802
The SB16 is pretty impressive, it's certainly not just using linear interpolation based on those measurements.

So IMHO something like libspeex-resample (windowed-sinc FIR filter) should be used for any audio resampling unless you specifically want the distortion of a bad resampler.


About fixing ResampleSfx.. I did try making a version using libspeex-resample, and still ran into 2 problems:
- When the mixer is running at 11kHz, quake can get away with cutting off and restarting sounds without fading in/out. The upsampling smooths out the discontinuities, and limits the glitching to be below 5.5kHz which prevents it from being too annoying. If the mixer is running at 44 or 48kHz you lose this safety net. Particularly: holding down fire with the nailgun creates really annoying high-frequency glitches when the nail firing sample is cut off midway through and restarted. This distracts me whenever I use DarkPlaces..

- The other related problem is Quake sfx tends to clip like crazy, especially if there is a lot of action happening. Like the previous point, clipping at 11kHz is no big deal because the upsampling limits the damage to below 5.5kHz, so you almost get a limiter/softclipper for free. Whereas at 44/48kHz clipping sounds awful and must be avoided at all costs.

I tried working around both of those, by making the mixer fade in/out when interrupting samples, and adding a limiter/softclipper, but couldn't get something I was happy with. So, for QS, ended up with a 11kHz->44kHz resampler (FIR filter) after the sfx mixer, before mixing in music.
Upgrading to a resampler that can do 48kHz, supporting float output, and moving to floats internally would be nice improvements for sure. 

idea: try installing ffdshow, this should add support for many other codecs to DirectShow. It might replace the mp3 decoder and magically fix your issue. Not sure if MarkV will play other formats like OGG/flac if DirectShow is capable of it, but that could be worth a try too. 

Thanks, those are some good troubleshooting ideas, but...

I disabled the Wifi adapter, no change.
Installed ffdshow, no change.
I have no anti-virus running.

It seems to be an issue with the encoding/decoding.

And I'm getting some really strange results that I can't explain.

I'm using CDex 1.77 (just updated from a slightly older version) to rip directly from the Quake CD with various encoding options.

The default encoder is set to "Lame MP3 Encoder 1.32," and if I leave it on the default settings (a range of 128 - 320 kbps with auto sample rate), it outputs a 256 kbps 44100 Hz, 11 meg file.

Mark V loads that file in 7 seconds...

If I only alter the option to lock the rate to 64 or 56 kbps, the file size drops to about 3.8 meg, but the MP3 then takes 11 seconds to load in Mark V. What's up with that??

Locking the rate at 256 kbsp makes a 15 meg file that only takes 9 seconds to load....

If I allow a variable rate from 48-96, it encodes at 96, but it then takes 16 seconds to load....

If I alter the Hz down to 32000 sometimes I can get it back down to a 7 second load time with other altered settings....

Eh, I just can't come up with any one thing that's affecting it in a predictable way.


Well, I have better luck changing the encoder in CDex to "Windows MP3 Codec" which says it's "Fraunhofer IIS MPEG Layer-3 Codec." It is much more limited, offering a max of 56 kbps, 22050 Hz, but the MP3 comes out at around 3.32 meg and only takes about 4.5 seconds to load.

If I change some things around and encode with the same settings using Lame, the file seems virtually identical at 3.31 meg, but takes 7 seconds to load. There are some other options in the Lame encoder, like "VBR method" which I have no clue about....

I've tried making sure I don't include ID3 tags, and that seems to make no difference.

Well, I think I've hit a wall with my testing. The "Windows MP3 Codec" will have to do, and I don't think I'm going to get a better result without using a drastically lower audio quality.

It's just... weird. 

Did you check memory usage during the freeze, and whether any disk swapping is happening in Task Manager?

tbh I would just format/reinstall Windows at this point, but I have low patience for troubleshooting and it's not always practical 

Maybe one last idea ... is hardware acceleration on?

Almost all hardware has the ability to decode mp3 (mp3 is part of the MPEG-2 standard).

https://www.pixelmetrics.com/Tips/VidBlank/MediaPlayer.php

Even thought the option says "video", audio is part of video.

Worth a last try maybe ... 

I tried altering the hardware acceleration settings in WMP, but got no difference (I use the file that causes the 17 second delay for testing, because the delay is very close to 17 seconds every time, like clockwork, though I did also try my newly-encoded file that only causes a 4.5 second delay, but any difference in that one would probably be small).

Watching the tack manager, when I'm just sitting with Quake running in a window, it says Mark V's memory usage is right around 215,920 K. CPU usage hovers around 50% (I get around 0% just watching this web page without Quake running, though it can spike up to 50% when I'm dragging windows around a lot).

When I switch on External Sounds in Mark V, while I'm experiencing the 17-second delay, Mem Usage jumps up to 222,100 or so (and my second processor seems to show slightly less usage on the graph, probably because the video in Quake is frozen).

Then after the 17 seconds, when the music starts playing, the Men Usage goes to around 221,956 K.

Turning the music off again drops me back to the original 215,920 K.

These numbers are pretty consistent.


At any point in the process I can easily switch around to other windows, and it does not feel bogged down or like it's out of memory or anything.... The page file seems to stay pretty constant too. Right now it's around 437 MB while I'm not playing Quake. Running DX Mark V makes it go up to about 888. It goes to around 895 when I enable the music (during and after the 17 second freeze), and right back down to 889 when I disable the music.


Yeahhh, I'm not gonna try to re-install Windows, heh.

And again, only in Mark V do I get this bizarre delay (well, and in DirectQ, which I tried earlier). Using WMP or VLC or Winamp, the MP3 starts up instantly, after the program loads. *shrug* 

DirectShow mp3 playback in Quake engines is not new. Mark V was nowhere near the first engine to use it.

FitzQuake 0.85 + mp3 support --- November 11, 2009 http://celephais.net/board/view_thread.php?id=60306&start=275

ProQuake with mp3 playback --- July 2010
http://quakeone.com/forums/quake-help/quake-clients/5698-mp3-option-proquake-4-36-a.html

DirectQ - A post from 2012 where someone is asking about mp3 and MH states that DirectQ has had mp3 playback for "about 3 years".
http://quakeone.com/forums/quake-help/quake-clients/7412-directq-1-8-8-a-3.html#post106070

Engine X - September 2010
http://quakeone.com/forums/quake-help/quake-clients/5942-engine-x-4-61-beta.html

Reckless (now known as Revelator) used DirectShow playback for his Realm engine (2010ish?)

And none of these engines were anywhere near the first to use it, probably an ancient MHQuake engine from 2003-2005 was. 

I'm pretty sure that I wrote the DirectShow code for DirectQ because I had this idea that I wanted to use DirectX components for everything. Older versions would have used the Windows Media Player SDK. You can also use MCI which is a little cleaner and more "C-like".

Unfortunately I'm in a similar situation to Baker and just don't have the time to put together experimental code to test all of this out.