playing large wav.files

You found a bug or have any issues? Please post them here!
Majesty
Posts: 19
Joined: 23 May 2012 20:37
playing large wav.files

Post by Majesty »

When I play large mp3 or wav.files the sound triggers now and then.
The sound get stagnates and triggers a bit and then proceeds and after a while the same thing and so on.
What can I do about it?
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: playing large wav.files

Post by radio42 »

Sounds like you are using a very old version of ProppFrexx, as I remove the Winamp DSP from the delivery already a year ago, as I found out, that this DSP was in various situations not stable and might have caused drop outs and even crashes.

However, most drop-out/hick-ups are NOT CPU related, but rather I/O related.
The CPUs in these days are typically never the bottlenack, but slower hard discs are typically.
Try increasing your buffer settings in this case.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: playing large wav.files

Post by radio42 »

Does that happen to all your 'large' wav/mp3 files or only to specific once?
ANd from where are you playing them - from a local hard disk or a NAS or network device?
I couldn't reprocuce such thing here - trying it with 2 or 3 hour long wav or mp3 files...
Also what kind of machine/OS are you using?
And what are your sound driver settings (driver model, like WDM, WASAPI or ASIO, buffer settings etc.)
Majesty
Posts: 19
Joined: 23 May 2012 20:37
Re: playing large wav.files

Post by Majesty »

My PC is strong enough to do great work. Not an issue here!
I'm playing the files from a portable drive.
The buffer settings are default. Asio Buffer size=512 samples.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: playing large wav.files

Post by radio42 »

So could it be, that your portable device isn't 'fast' enough to deliver the data to the audio engine.
Note, that this has nothing to do with the CPU speed, but is simply related to the I/O speed!
An ASIO buffer size of 512 means (assuming that the file has a sample rate of 44100Hz), that the device (your hard disk) must deliver 512 samples every 10 milliseconds.
(512 / 44100 = 10ms)
And if the device (your hard disk) is at any point in time not capable of doing that you'll recognize glitches in the sound.

So I assume, it is related to your hard disk speed!
Try putting those large files to e.g. a faster local hard disk and try it again...
Or increase your ASIO buffer size.
Majesty
Posts: 19
Joined: 23 May 2012 20:37
Re: playing large wav.files

Post by Majesty »

Great! Thanks!
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: playing large wav.files

Post by radio42 »

Great?
So what was your issue?
did you increase the buffer size or did you moved to a faster hard disk?
szal77
Posts: 77
Joined: 22 Jul 2012 16:01
Location: Mönchengladbach, Germany
Re: playing large wav.files

Post by szal77 »

@ Majesty: If I get you correctly, then this is probably a similar issue to what I’ve been experiencing every now and then. I usually don’t play exceptionally large files in ProppFrexx though, and ProppFrexx needs to have been playing for several hours on end for this to occur here—doesn’t seem to matter whether continuously or with playback having been stopped in between without restarting ProppFrexx. My machine is an AthlonII X2 255 (2× 3.1 GHz) with 8 GB RAM—unfortunately not dedicated—, OS is Windows 7 x64, and I play files exclusively from my hard drives (both IDE (UDMA133) and SATA (6 Gb/s)). I have even had this occurring with microphone input in the past (though that was on another, slower, machine running Windows XP).

It is worth noting that the ‘triggering’, as Majesty calls it, will not be audible on a recording done from within ProppFrexx or on the stream when broadcasting the signal directly from ProppFrexx to the streaming server, i.e., not using a hardware mixer in between. When this happens with the microphone input, a few seconds of the microphone passage will be cut out of the stream. I can provide an example of this on request. And after this has happened, the reaction time of the microphone input will be back to normal; before that the microphone input will lag, sometimes several seconds. This occurs especially after ProppFrexx did a lot of loading files, either during normal playout in the playlists or by pre-listening on the PFL player.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: playing large wav.files

Post by radio42 »

I am not certain I understand you correctly.

'Majesty' seemed to have an issue with playing large files from a 'slow' harddisk, which 'skipped' sometimes ('triggered' as he called it).
This probably was due to using a low-latency audio driver (ASIO in his case) and the hard disk not being able to deliver a steady I/O performance - meaning the data couldn't be delivered fast enough from the hard disk at some point in time.

What you describe more sounds like an Input issue, that the input is lagging or skippes recorded samples ('a few seconds will be cut')?!
Can you explain this in a bit more detail? Are you recording an input-mixer-channel?
And when exactly is this happening? In the middle of such recording or when toggling the recording on/off (and as such always at the beginning or end)?
szal77
Posts: 77
Joined: 22 Jul 2012 16:01
Location: Mönchengladbach, Germany
Re: playing large wav.files

Post by szal77 »

Sorry for being late to answer, I’ve been a bit busy lately…

Just to try to prevent misunderstandings here: I’m not saying that Majesty’s issue and mine are related, just that the symptom is somewhat similar.

As for the skipping: I am recording a sum signal, consisting of 1 or (during track change) 2, at most 3, player signals, an occasional cardwall player signal (manual drop-ins), and an input mixer channel signal carrying the microphone (muted and unmuted as needed). During playout tracks are loaded into the players when the playlist advances (or when calling up the PFL player, or when switching to the cardwall the first time after starting ProppFrexx). This loading seems to increase buffer times, the effect of which is the input mixer channel signal starting to lag. In the same fashion, the monitor output signal, which is copied from the above mentioned sum signal, starts to lag as well. (This monitor output signal is for playing to my speaker boxes when desired; during show broadcasting this channel is muted.)

Trying to visualize my settings:

Deck A (NONE)
• [ii] Deck B (NONE)
• [iii] Deck C (NONE)
• [iv] Cardwalls (NONE)
• [v] Standby Players (NONE)

all routed to ?

• [1] Sum Channel (NONE)
• added here: [M] Input Mixer Channel (WASAPI, from Creative Emu10k1 PCI sound device)

routed to ?

• [2] Sum Channel for broadcasting, running a DSP for final limiting (WDM, on Creative Emu10k1 PCI sound device)
This channel is monitored via headphones.

further routed to ?

• [3] Monitor Channel for speaker boxes (WDM, on on-board HD Audio sound device)

The channel designated as [2] never lags or anything. What does lag, increasingly the longer ProppFrexx plays, are the input channel [M] and the monitor channel [3]. And then, at one point, the buffer seems to overflow, causing the ‘skipping’ to be audible on channel [2]; this seems to clear the buffer, because at the same time the signal on monitor channel [3] will jump, causing the output to miss a couple seconds or so (if you know the song playing, you know when something isn’t right; kind-of like when you bump at a record player and the needle jumps a bit further into the track, only with no audible crackling from the needle taking off from the record and falling back on the surface 1 or 2 track widths further in; I hope you get what I mean here :)). Also the lag on the input mixer channel will at that point disappear. In my experience so far, this will have NO audible influence on either the broadcasting (what the listener hears on their player) or the recording.

Afaics, the fact that I am recording does not have any influence on this behaviour. There is no problem when starting or stopping the recording, and the same behaviour can be exhibited during long playout sessions when not recording and/or broadcasting. The skipping does not necessarily occur on track change or when playing a manual drop-in from the cardwall; most often it’s totally out of the blue somewhere in the middle of a track playing. Also I have never had the PFL player lag so far.

I hope I was able to make my point clearer.

Post Reply