Are you playing the same stream in the BASS_ChannelPlay calls, or is it a new stream each time? If it is the same stream, then the previous BASS_ATTRIB_PAN setting should still apply, but a new stream will start with its BASS_ATTRIB_PAN set to 0. If you would like new streams to start with a different BASS_ATTRIB_PAN setting, you could create a wrapper function that does that...

HSTREAM StreamCreateFile(const char *filename, DWORD flags)
{
HSTREAM r=BASS_StreamCreateFile(FALSE, filename, 0, 0, flags);
if (r) BASS_ChannelSetAttribute(r, BASS_ATTRIB_PAN, pan);
return r;
}

Or when starting playback...

BOOL ChannelPlay(DWORD handle, BOOL restart)
{
BASS_ChannelSetAttribute(handle, BASS_ATTRIB_PAN, pan);
return BASS_ChannelPlay(handle, restart);
}

As you're using hotmail, you may need to check your junk/spam box too ... If it isn't in there either, do you have another email address that we could try? You can PM it to me, if so.

There doesn't appear to be anything unusual about your uploaded MP3 files, so it's a bit puzzling. Are you having the problem only with them, or is it all MP3 files? What about other file formats, eg. WAV or OGG? For a C/C++ test to compare with, please try the CONTEST example from the standard Linux BASS package.

If you're using a mixer (BASS_Mixer_StreamCreate/etc), then the mixer will apply its sources' BASS_ATTRIB_VOL settings when generating the mix. In other cases, the BASS_FX add-on's BASS_FX_BFX_VOLUME effect can be used via BASS_ChannelSetFX.

That code looks mostly fine, but note that the BASS_STREAM_PRESCAN flag is not valid with BASS_Mixer_StreamCreate and the BASS_STREAM_DECODE flag is not valid with BASS_Mixer_StreamAddChannelEx, so they should be removed from those calls. A list of valid flags can be found in each function's documentation. Using invalid flags can lead to unexpected results if their values happen to coincide with valid flags, eg. BASS_STREAM_PRESCAN = 0x20000 = BASS_MIXER_NONSTOP.

If it's still not working properly, please confirm what the "DurationsOfStreams" values are based on. The BASS_Mixer_StreamAddChannelEx "offset" and "length" parameters are byte offsets based on the mixer's sample format, so the "DurationsOfStreams" values would need to be too. If they are currently based on the source's sample format, then you could convert them like this...

QWORD mixerbytes=BASS_ChannelSeconds2Bytes(mixer, BASS_ChannelBytes2Seconds(source, sourcebytes)); // source bytes -> seconds -> mixer bytes

It looks like you have already found the answers to your earlier questions, but just to confirm... a mixer source will indeed begin playing from its current position, and the BASS_Mixer_StreamAddChannelEx "length" parameter can be used to stop a source early.

OK. So it isn't actually a deadlock (eg. the program/window is still responsive), but something is hogging the CPU? Are you sure the problem was happening when the "machine2" dump file was generated? There doesn't appear to be anything unusual going on in it. The "machine1" Process Explorer screenshot seems to show that the high CPU usage is in the stream's download thread though, so I will send you a debug version to log what happens in that.

Yep, BASS_ChannelGetData will deliver the requested amount of data (if available) regardless of tempo settings.

To expand on what I said above, BASS_ChannelSetPosition is always based on the original data rate, not the tempo-affected rate. The same goes for BASS_ChannelGetPosition and BASS_ChannelGetLength. For example, if you've set the tempo to 200% and decode 100000 bytes via BASS_ChannelGetData, the position reported by BASS_ChannelGetPosition will have advanced by 200000 bytes.

Please upload the MP3 file to have a look at here...

   ftp.un4seen.com/incoming/

Also, if you are currently using the "mp3-free" BASS version, please check if the standard BASS version has the problem too.

It's a BASSMIDI.DLL update, not BASS.DLL

No, unfortunately there is still no way to cancel a stream creation call. BASS_Free does cancel them (on the same device), but not any more quickly, eg. pre-scanning will still be completed first. I'll look into improving that in the coming days, and hopefully come back with something. I'll also give the "abort thread" idea (mentioned in the linked thread) some more thought.

Regarding making the pre-scan info retrievable, one issue is that the info structures may change in future, making the previously retrieved/stored info invalid. Similarly, the file could have been modified since the info was retrieved. But perhaps there are ways to guard against that causing too much trouble. I'll look into that too.

I'll send you a debug version to find out what the filetype filters look like (and hopefully reveal what the problem is).

BASS_ERROR_FILEFORM indicates that BASS_StreamCreateFile didn't recognise the file's format. To confirm whether the problem is specific to the ARM Linux version, please check if BASS is able to play that file (love.mp3) on any other platforms, and also check whether other software is able to play it.

BASS_ERROR_FILEOPEN indicates that BASSCD was unable to connect to the CDDB server. The default BASS_CONFIG_NET_PROXY setting is "" and the default BASS_CONFIG_CD_CDDB_SERVER setting is "freedb.freedb.org", so there should be no need to set those yourself. Do you still get the problem if you remove those BASS_SetConfigPtr calls? If so, to narrow down where the problem lies, please check if the FreeDB option is working OK in the pre-compiled CDTEST.EXE example (in C\BIN folder of BASSCD package).

Ah! It looks like there was indeed a problem with a mixtime BASS_SYNC_MIDI_TICK sync's SYNCPROC function setting another sync only a short distance ahead. Here's an update that should fix the problem...

   www.un4seen.com/stuff/bassmidi.dll

It should now be possible to do something like this...

BASS_ChannelSetSync(midi, BASS_SYNC_MIDI_TICK|BASS_SYNC_MIXTIME|BASS_SYNC_ONETIME, 0, TickSyncProc, (void*)0); // set onetime sync at 1st tick
BASS_ChannelPlay(midi, FALSE); // start playing

...

void CALLBACK TickSyncProc(HSYNC handle, DWORD channel, DWORD data, void *user)
{
DWORD tick=(DWORD)user; // current tick
tick+=tickstep; // next tick
BASS_ChannelSetSync(channel, BASS_SYNC_MIDI_TICK|BASS_SYNC_MIXTIME|BASS_SYNC_ONETIME, tick, TickSyncProc, (void*)tick); // set onetime sync at next tick
// do whatever else you want here...
}

How are you checking whether the marker position is valid, ie. what are you comparing the "marker.pos" value with? If you have an example MIDI file that demonstrates the problem, please upload that to have a look at here...

   ftp.un4seen.com/incoming/

Actually, it looks like what you want is possible after all. When PulseAudio is used, BASS's "Default" recording device (device number 0) should capture from PulseAudio's default input device. So you just need to set PulseAudio's default input device to the monitor that you want, eg. in the PulseAudio Volume Control app (Input Devices options page). The RECTEST and LIVESPEC examples capture from the default device, so you could use them to quickly test things after setting PulseAudio's default input device.

Seeking is not affected by the tempo, eg. if you call BASS_ChannelSetPosition with byte position 1000000, that is where it will go regardless of the BASS_ATTRIB_TEMPO attribute setting.

If you would like to work out how the tempo processing will affect the amount of data produced, you can use BASS_FX_TempoGetRateRatio, something like this...

newlength=origlength/BASS_FX_TempoGetRateRatio(handle);

I don't think that is currently possible, but I will check if something can be done about that.

Yes, an ARM Linux version of the BASSMIDI add-on has now been added to the package in the 1st post.

I've tried your suggestion and it turns out that it is a conflict among plugins after all.

Were you able to narrow it down to a particular plugin that's causing the problem? If that's proving tricky, I could send you a debug version to confirm what the filetype filters look like.

I know we already working on one thing here, but there's something else I'd like to ask you about. I've noticed that if you open either a directory of files, or just any number of files together that the order in which they are listed in the playlist varies. Is that by design?

By default, XMPlay doesn't do any sorting of new tracks. When using the file selector, the files are added to the list in the order that the file selector provides them, which I believe is the most recently selected one first and then the rest of the selected files in the order that they appear in the file selector (the same as Windows Explorer does). When loading a directory, the files are added in the order that Windows (FindFirstFile/FindNextFile functions) provides them.

As raina mentions, you can enable the "Auto-sort by filename" option to have XMPlay sort the new tracks by filename.