Encoder

Hi
I’m looking for some advice help or advice with 2 encoder “issues”, please.

  1. I am setting up the encoder to stream to an Icecast server. We use a mp3 stream at 80kb/s, joint stereo, at 44100 sample rate normally through a stand alone edcast programme - which works OK. I’ve entered the same parameters into the encoder, but it only gives a sample rate of 32000. I’m using the latest version of Lame, so any thoughts?

  2. We have an optimod pc v1100 v2 sound card; I’ve set mairlist up with 1 player using front 1/2 output - this plays into the optimod wave input. When I press the “live” button on the encoder it streams the wave out (i.e. processed signal) from the optimod which is exactly what we want. The problem is that there is some crackling accompanying the audio. It’s not really loud but would be irritating over a period. [By using the player straight into the encoder this crackling is not present, but neither is the optimod in circuit] Again, any thoughts?

Thanks

Al

  1. I believe 32kHz is the default sample rate for 80kbps output, so LAME is resampling the audio. It might be possible to force it to 44.1kHz by using the “–resample” command line option (specified as an extra encoder option in the connection setup in mAirList):
--resample sfreq sfreq = 8, 11.025, 12, 16, 22.05, 24, 32, 44.1, 48 Select output sampling frequency (only supported for encoding). If not specified, LAME will automatically resample the input when using high compression ratios.
  1. Can you please try to add an aircheck as an extra connection, preferably in WAV format, and see if the crackling occurs there as well. If so, the problem is most likely related to the sound card input or recording. If the WAV is ok, the problem is either LAME or the server connection. I heard that some people had to enter explicit LAME quality settings to make the output sound clear.

Hi Torben

Will do, many thanks.

Al

Hi Torben

The re-sample worked fine, thanks.
Unfortunately, the Wav file had the crackling on it too, so I’ll be looking at the sound card/driver.

It may be that we have to use the edcast which would be a shame as mairlist updates the metadata.

Late update: I now have edcast updating the now playing metadata.

Thanks again.

Al

Good to hear that you found a workaround for the moment. This gives us some time to sort this out.

I do have an idea what the problem is. I suspect that it’s buffer underruns from the recoding sound card - the encoder is processing the data faster than the recording soundcard provides it. I have come across this problem the other day when I was rewriting the audio input code for mAirList 4.1 (which will feature voice track recording, as you know). The new code in v4.1 will include a nice solution for the underrun problem that will actually take into account the latency of all affected sound cards. The code is not compatible with v4.0 though, so to work around this issue, we need another solution.

I believe it should suffice to add an extra sleep() call so that BASS can buffer some more milliseconds of live audio before it is actually added to the encoder output. Of course this will increase the recording latency, but that shouldn’t really be so important here.

I have just uploaded Build 1207 which adds the ability of doing so, through an undocumented ini file setting for the moment. So install that snapshot, open your encoder.ini file (see mAirListConfig -> Advanced -> Data Folders for the exact location), go to the [Record] section, and add the following line:

ExtraSleep=500

Start with a relatively large value, say 500ms as in the example above, and see if the crackle goes away. If it does, you can try to lower the value step by step.

Hi Torben

Thanks, I will give this a try. It may take a day or so as I work on this remotely via teamviewer.

Al

Nice one!

I’ve experimented with various delays and have taken it as low as 50mS with some success, but 300mS seems to cope with all varieties of audio so far.

I think you’ve solved it.

Thanks again

Al

I’ve done some further tests, mainly with variable bit rate encoding, and have settled for 500mS.

Al

Hi Torben

I’ve carried out yet more tests this time using a creative audigy sound card. The crackles seem to appear over a period of several minutes. I’ve varied the extra sleep from zero to 1sec and it appears as I say after some time.
Whilst the crackling is present I have stopped the audio using the “live button” for 2 seconds and then started it again; the audio runs clean and then starts crackling after a period.
I’m in the process of updating the sound card drivers, to see if that helps.

I’d be interested to see what your German colleagues report back.

Al

Generally the ExtraSleep approach seems to cure the problem for most people.

So with the Audigy card, the crackling reappears after some minutes, even when the sleep is set to one second? That puzzles me, because one second should REALLY be enough to keep the buffer full at any time.

I recall the BASS developer mentioning that there are sound cards that fail to “lock” to the sample rate, providing the data a little bit slower that requested - this will eventually lead to a buffer underrun. I’m not sure if the Audigy cards are known to be affected by this problem. I could try to build a debug version that reports the amount of buffered data continuously into a log file.

I updated the Audigy sound card drivers. I created some mp3 aircheck recordings using the same 3 items. The approx. length of each clip is 6 minutes. The format 80kbs with 44.1 sampling rate.

With zero extra sleep the crackles are audible from 20 seconds in.
With 500mS the crackles start after approx 3 minutes
With 1 sec the crackles are starting after 6min 30 secs

We intend to use the optimod on air, the audigy may be required as a standby from my home - hence the experiments.

Coming back to the original post:
When the mairlist plays the audio and edcast encodes - no crackles.
When mairlist plays & encodes - crackles.

If there will be a proper solution in time, then this should suffice for the present - unless this helps with the development.

[quote=“Allan Smart, post:11, topic:7665”]With zero extra sleep the crackles are audible from 20 seconds in.
With 500mS the crackles start after approx 3 minutes
With 1 sec the crackles are starting after 6min 30 secs[/quote]

This supports the theory that the actual rate at which the sound card delivers the data is slightly slower than the requested sample rate, so the signals slowly drift apart. If the 1s extra buffer is eaten up within ~6 minutes (360 seconds), that means that the soundcard is 0.28% too slow, in other word, is delivering the sample data at about 44.0kHz instead of 44.1kHz. We should be able to confirm this by the special debug version I shall build (not today though).

I have found a forum post saying that this is a typical problem for Soundblaster cards, and you should try using 48kHz recorcing: http://homerecording.com/bbs/general-discussions/digital-recording-computers/does-any-soundblaster-audigy-2-nx-not-lag-254406/#post2821422

Regarding Edcast vs. mAirList, the thing is that mAirList’s encoder actually has two inputs: The live input from the soundcard, and the “player input” that receives all audio from the players that are set to direct “Encoder” output. Even if no player is set to “Encoder”, that “input” is still active, but there’s only silence on it. Both inputs are mixed together in a synchronized mixer that runs at exactly the desired sample rate. When one of the inputs is becoming too slow, you will hear crackles, because the other input won’t “wait” for it.

Edcast is different, it will only record from the sound card, no internal player input involved. So there’s no synchronization and no crackling. However, your listeners might notice that their player keeps rebuffering after a while. If their player buffer is 5 seconds, then probably every 30 minutes :wink:

EDIT: Another post supporting the theory: http://forums.creative.com/showthread.php?t=372661&s=15df4331b37341a6218137bf83eb6094&p=132183&viewfull=1#post132183

EDIT2: Just uploaded snapshot #1212 that lets you specify a different sample rate for the recording sound card in encoder.ini, [Record] section:

SampleRate=48000

The encoder itself will continue to run at the sample rate specified in the configuration (default 44100). mAirList/BASS will perform the resampling of the record input, which should be more accurate than what the broken Audigy chip/driver produces.

The saga continues!
The creative is set at 48kHz 16 bits: Snapshot downloaded.
The [Record] is set at 48kHz with no extra sleep.
I have just made 4 separate aircheck recordings varying between 4 and 10 minutes each. Each recording was done by pre-loading the playlist with audio and set to run in Auto mode. The sequence of recordings being 1,2,3,4.
Recording numbers 1, 2 and 4 were made in this sequence: a. connect encoder, b click live and then start the auto playlist off.
Each recording has clean audio.
Recording 3, however, was made in this sequence: a. start the auto playlist off, b click live, c connect encoder. This has crackles from the beginning.

Hmmm… Can you also try:

a. click live
b. connect encoder
c. start auto playback

This combination runs clean also.