▲

[thirtyparity]

What is the best device to use bass with its optimal performance?

[simon.chen]

hi, Ivan

i use BASS_ChannelSetSync method to do something when Play to End. but my SYNCPROC was not called.

private SYNCPROC _mySyncProc;
...
_mySyncProc = new SYNCPROC(MySync);
musicHandle = Bass.BASS_StreamCreateFile(this.mp3FilePath + this.mp3FileName, 0, 0, 0);
if (musicHandle != 0)
{
    if (Bass.BASS_ChannelPlay(musicHandle, true))
   {
         Bass.BASS_ChannelSetSync(musicHandle, BASSSync.BASS_SYNC_END | BASSSync.BASS_SYNC_ONETIME, 0, _mySyncProc, IntPtr.Zero);
    }
}

private void MySync(int syncHandle, int channel, int data, IntPtr user)
{
     ....//
}

and, when it stop itself at the pos 34185544(Total is 34246656), not the end. not only one mp3 file, but also all my mp3 file is stoped at nearly the end, but not the end. so my SYNCPROC cannot be called. Is there any wrong?

[EEh]

It possible to get sound output breaks when WiFi and Bluetooth are turned on at one time.

I suppose, it happens because of playback BASS thread is displaced by threads with higher priority (like WiFi and Bluetooth threads as in our case). Device buffer size increasing (BASS_CONFIG_DEV_BUFFER) does not solve proplem. Also, I was trying to turn off auto-updates in BASS and make my own updates (BASS_ChannelUpdate, BASS_Update) from thread with higher priority value than BASS uses (I set windows ce priority to 128), but sound breaks are still audible.

How can I control and change BASS playback thread priority value? Is it possible to make new config option (BASS_SetConfig)?

OS: Windows Mobile 6.1

[Ian @ un4seen]

What is the best device to use bass with its optimal performance?

Are you referring to the CPU used by the device, eg. ARM/MIPS/x86?

i use BASS_ChannelSetSync method to do something when Play to End. but my SYNCPROC was not called.

private SYNCPROC _mySyncProc;
...
_mySyncProc = new SYNCPROC(MySync);
musicHandle = Bass.BASS_StreamCreateFile(this.mp3FilePath + this.mp3FileName, 0, 0, 0);
if (musicHandle != 0)
{
    if (Bass.BASS_ChannelPlay(musicHandle, true))
   {
         Bass.BASS_ChannelSetSync(musicHandle, BASSSync.BASS_SYNC_END | BASSSync.BASS_SYNC_ONETIME, 0, _mySyncProc, IntPtr.Zero);
    }
}

private void MySync(int syncHandle, int channel, int data, IntPtr user)
{
     ....//
}

and, when it stop itself at the pos 34185544(Total is 34246656), not the end. not only one mp3 file, but also all my mp3 file is stoped at nearly the end, but not the end. so my SYNCPROC cannot be called. Is there any wrong?

I tested setting an END sync just now, and it was fine. It shouldn't be file-specific, but if you like, you can upload a troublesome file to try here...

   ftp.un4seen.com/incoming/

Btw, I would recommend setting the sync before starting playback; if the stream is very short, setting the sync afterwards may be too late.

It possible to get sound output breaks when WiFi and Bluetooth are turned on at one time.

I suppose, it happens because of playback BASS thread is displaced by threads with higher priority (like WiFi and Bluetooth threads as in our case). Device buffer size increasing (BASS_CONFIG_DEV_BUFFER) does not solve proplem. Also, I was trying to turn off auto-updates in BASS and make my own updates (BASS_ChannelUpdate, BASS_Update) from thread with higher priority value than BASS uses (I set windows ce priority to 128), but sound breaks are still audible.

How can I control and change BASS playback thread priority value? Is it possible to make new config option (BASS_SetConfig)?

It looks like the device output thread (which mixes the buffers and feeds the device) would be left at default priority when it was intended to be at "time critical". An updated DLL to correct that is in the package now (see 1st post). Let me know if you still have the problem with it, and if so, I'll look into using an even higher priority.

[EEh]

It looks like the device output thread (which mixes the buffers and feeds the device) would be left at default priority when it was intended to be at "time critical". An updated DLL to correct that is in the package now (see 1st post). Let me know if you still have the problem with it, and if so, I'll look into using an even higher priority.

Hi Ian,

I have tested new updated dll - sound breaks are still exist  (approx. 30 breaks during 10 minutes of playback) . Furthermore, I discover a new problem - sometimes sound output does not actually started after BASS_ChannelPlay is called. I.e. after succesfuly called BASS_ChannelPlay() there is no realy playback happens and BASS_ChannelIsActive returns 0. Such behaviour of BASS_ChannelPlay() is new (with earler bass.dll it works fine)- possible it's a bug.

[Ian @ un4seen]

I have tested new updated dll - sound breaks are still exist  (approx. 30 breaks during 10 minutes of playback)

Do either of the BASS_CONFIG_BUFFER and BASS_CONFIG_DEV_BUFFER settings make any difference with the updated DLL?

Do you happen to know what priority the WiFi/Bluetooth threads on your device are running at? Perhaps the problem is that they are running at a higher priority than the audio driver? Do you get the breaks in playback with any other software? If you haven't already done so, please also try to reproduce the problem with the pre-compiled examples.

Furthermore, I discover a new problem - sometimes sound output does not actually started after BASS_ChannelPlay is called. I.e. after succesfuly called BASS_ChannelPlay() there is no realy playback happens and BASS_ChannelIsActive returns 0. Such behaviour of BASS_ChannelPlay() is new (with earler bass.dll it works fine)- possible it's a bug.

That's strange, as the only change in the update was the thread priority, which shouldn't affect that stuff. Is there any pattern to the problem, eg. a particular file or length of file? Also, is the BASS_ChannelPlay call always successful, ie. returning TRUE?

If you could create a small example to reproduce the problem with, that would be most useful.

[simon.chen]

i use BASS_ChannelSetSync method to do something when Play to End. but my SYNCPROC was not called.

private SYNCPROC _mySyncProc;
...
_mySyncProc = new SYNCPROC(MySync);
musicHandle = Bass.BASS_StreamCreateFile(this.mp3FilePath + this.mp3FileName, 0, 0, 0);
if (musicHandle != 0)
{
    if (Bass.BASS_ChannelPlay(musicHandle, true))
   {
         Bass.BASS_ChannelSetSync(musicHandle, BASSSync.BASS_SYNC_END | BASSSync.BASS_SYNC_ONETIME, 0, _mySyncProc, IntPtr.Zero);
    }
}

private void MySync(int syncHandle, int channel, int data, IntPtr user)
{
     ....//
}

and, when it stop itself at the pos 34185544(Total is 34246656), not the end. not only one mp3 file, but also all my mp3 file is stoped at nearly the end, but not the end. so my SYNCPROC cannot be called. Is there any wrong?

I tested setting an END sync just now, and it was fine. It shouldn't be file-specific, but if you like, you can upload a troublesome file to try here...

   ftp.un4seen.com/incoming/

Btw, I would recommend setting the sync before starting playback; if the stream is very short, setting the sync afterwards may be too late.

[/quote]

it was fine to get a END sync, but in the MySync, if i do some UI update, the Procedure Losing Control(debug step by step, but the process state turn into running state and not extcute the next statement), so i use the Invoke() method to do UI update, it work fine now.

[radio42]

Yes, that is totally normal.
The SYNCPROC will always execute in a thread created by BASS and not in your UI thread.
But any UI updates must be executed in the main UI thread...so you need to call Invoke/BeginInvoke in order to ensure you are back on the UI thread.

[Bergamin]

Hi,

When I run the following command line with the BassNet.Compact :

Code SelectExpand

BassEnc.BASS_Encode_Start(streamRec, "output.wav", BASSEncode.BASS_ENCODE_PCM, null, IntPtr.Zero);Return a message :
This application requires a newer version of the Microsoft® .NET Compact Framework than the version installed on this device.

[radio42]

Yep, that indicated, that you have only the .Net compact framework 1.1 installed on the device.
But BASS.Net compact requires the .Net compact framework 2.0 to be installed ;-)

[Bergamin]

    
I'm using the CompactFramework 2.0.
Even the application is running normally.
It is this line and runs normal:

Code SelectExpand

streamRec = Bass.BASS_RecordStart(44100, 2, BASSFlag.BASS_RECORD_PAUSE, myRecordProc, IntPtr.Zero);

[Bergamin]

   
Using this example code on a HTC Touch (WM6), the recording is stopped suddenly after 20 seconds.

Anyone know why I respond?

Thank you!

Code SelectExpand

private RECORDPROC _myRecProc; // make it global, so that the Garbage Collector can not remove it
...
Bass.BASS_RecordInit(-1);
_myRecProc = new RECORDPROC(MyRecording);
// start recording paused
int recChannel = Bass.BASS_RecordStart(44100, 2, BASSFlag.BASS_RECORD_PAUSE, _myRecProc, IntPtr.Zero);
...
// really start recording
Bass.BASS_ChannelPlay(recChannel, false);
...
// the recording callback
private bool MyRecording(int handle, IntPtr buffer, int length, IntPtr user)
{
  return true;
}

Code SelectExpand

EncoderWAV wav = new EncoderWAV(recHandle);
wav.InputFile = null;
wav.OutputFile = "test.wav";

wav.Start(null, IntPtr.Zero, false);

// your recording will be encoded until you call...
wav.Stop();

[jwinder]

Can anyone here help with my issue in this thread: http://www.un4seen.com/forum/?topic=10332.0

Sorry, I might have been better posting it in this topic in the first place!

[EEh]

Do either of the BASS_CONFIG_BUFFER and BASS_CONFIG_DEV_BUFFER settings make any difference with the updated DLL?

The only difference that I heard is that playback latency increased (I enlarged device buffer (up to 400-600ms from 200) and playback buffer (up to 1000ms from 500ms), also I ran tests in which  device buffer length equals playback buffer (400 - 500 ms) ). Sound breaks was audiable.

Do you happen to know what priority the WiFi/Bluetooth threads on your device are running at? Perhaps the problem is that they are running at a higher priority than the audio driver? Do you get the breaks in playback with any other software? If you haven't already done so, please also try to reproduce the problem with the pre-compiled examples.

I ran netradio example from package - it confirms a problem on my device. Also I descovered that BASS uses priority value 248 for playback and 250 (or 249?) for update in new version ( in old version was 249 and 250 respectively). On the other hand, MS windows media player (wmplayer.exe) uses 150 and 247 priority values and sound plays more clearly (1-2 sound breaks against 30 breaks from BASS player). Furthemore, player's behaviour tightly depends on device's vendor and OS firmware. I am using HTC with WM6.1 and Samsung with WM6.5 on board, and I need to  customize BASS player's threads priorities for each environment.

Can you introduce new config options to control BASS thread priorities? (NOTE: using of SetThreadPriority(THREAD_PRIORITY_TIME_CRITICAL) is not reasonable, beacause I want set up more higher priorities than 248 (with more lower value in Windows CE). See CeSetThreadPriority() for this case)

That's strange, as the only change in the update was the thread priority, which shouldn't affect that stuff. Is there any pattern to the problem, eg. a particular file or length of file? Also, is the BASS_ChannelPlay call always successful, ie. returning TRUE?

Yes, BASS_ChannelPlay returns TRUE, but sometimes playback does not starts after that. Playing the same data later may be successful. This problem is not always reproducible . I suppose, it may happen because of priority difference beetwen of playback and update threads (for example if update thread was forcing out from execution by playback).

[Ian @ un4seen]

Using this example code on a HTC Touch (WM6), the recording is stopped suddenly after 20 seconds.

To narrow-down where the problem is, please try to reproduce that with the pre-compiled RECTEST.EXE example.

I ran netradio example from package - it confirms a problem on my device. Also I descovered that BASS uses priority value 248 for playback and 250 (or 249?) for update in new version ( in old version was 249 and 250 respectively). On the other hand, MS windows media player (wmplayer.exe) uses 150 and 247 priority values and sound plays more clearly (1-2 sound breaks against 30 breaks from BASS player). Furthemore, player's behaviour tightly depends on device's vendor and OS firmware. I am using HTC with WM6.1 and Samsung with WM6.5 on board, and I need to  customize BASS player's threads priorities for each environment.

Can you introduce new config options to control BASS thread priorities? (NOTE: using of SetThreadPriority(THREAD_PRIORITY_TIME_CRITICAL) is not reasonable, beacause I want set up more higher priorities than 248 (with more lower value in Windows CE). See CeSetThreadPriority() for this case)

OK, an update with configurable priority of the device output thread is in the package now (see 1st post). It adds the following BASS_SetConfig option:

Code SelectExpand

#define BASS_CONFIG_DEV_PRIORITY 31
That should be set before calling BASS_Init; subsequent changes won't take effect until the next BASS_Init call. It can be set between 1 and 255 (0=leave default: time critical), as described here:

   http://msdn.microsoft.com/en-us/library/bb202761.aspx

Please report how you get on with it.

Yes, BASS_ChannelPlay returns TRUE, but sometimes playback does not starts after that. Playing the same data later may be successful. This problem is not always reproducible . I suppose, it may happen because of priority difference beetwen of playback and update threads (for example if update thread was forcing out from execution by playback).

Was that with internet streams or local files? If the former, could it have been stalled, waiting for data to arrive? What does BASS_ChannelIsActive say about it?

[EEh]

Yes, BASS_ChannelPlay returns TRUE, but sometimes playback does not starts after that. Playing the same data later may be successful. This problem is not always reproducible . I suppose, it may happen because of priority difference beetwen of playback and update threads (for example if update thread was forcing out from execution by playback).

Was that with internet streams or local files? If the former, could it have been stalled, waiting for data to arrive? What does BASS_ChannelIsActive say about it?

BASS_ChannelIsActive returns BASS_ACTIVE_STALLED.

I tested new version of updated dll and descover that update and playback threads must have EQUALS priorities, otherwise we have a bug described above (sometime playback does not starts and stalls after play).

Can you introduce config option for update thread priority too? (as it was done for device output).

NOTE that BASS at this time uses default settings for priorities (248 (output) and 249 (update)) that are not correctly working. (in inital version was 249 for both)

[Ian @ un4seen]

BASS_ChannelIsActive returns BASS_ACTIVE_STALLED.

Was that with an internet stream or a local stream? If an internet stream, please check what BASS_StreamGetFilePosition (BASS_FILEPOS_BUFFER) says about the download buffer level.

I tested new version of updated dll and descover that update and playback threads must have EQUALS priorities, otherwise we have a bug described above (sometime playback does not starts and stalls after play).

Can you introduce config option for update thread priority too? (as it was done for device output).

NOTE that BASS at this time uses default settings for priorities (248 (output) and 249 (update)) that are not correctly working. (in inital version was 249 for both)

I'm not sure it's a good idea to set the update thread to a very high priority, as if it hogs the CPU it could effectively lock-up the device, eg. the GUI could become unresponsive due to getting no CPU and the user can't close the app. The same could be said for the device output thread, but that generally has less work to do, so it is less likely to hog the CPU. Btw, in the initial versions, the device output thread was actually accidentally a lower priority than the update thread (251 vs 249); they were never the same priority.

Are you able to monitor the CPU usage on your device, and if so, what does that say about the processes/threads?

[EEh]

Was that with an internet stream or a local stream? If an internet stream, please check what BASS_StreamGetFilePosition (BASS_FILEPOS_BUFFER) says about the download buffer level.

I use BASS_StreamCreateFileUser to pump data from my own data storage. I want notice that I have a problem with playback only if playback thread priority is 248 or lower. I.e. when playback thread has priority as device driver. ( in CE time critical priority will be mapped to 249 ).

I'm not sure it's a good idea to set the update thread to a very high priority, as if it hogs the CPU it could effectively lock-up the device, eg. the GUI could become unresponsive due to getting no CPU and the user can't close the app. The same could be said for the device output thread, but that generally has less work to do, so it is less likely to hog the CPU. Btw, in the initial versions, the device output thread was actually accidentally a lower priority than the update thread (251 vs 249); they were never the same priority.

Are you able to monitor the CPU usage on your device, and if so, what does that say about the processes/threads?

Yes, its may be overhead for CPU, but I want to experement with it. At this time I use some hack to adjust update thread priority - I wrote some code that searches update thread, gets its thread id, converts ID to HANDLE (in CE are the same) and with using of CeSetThreadPriority sets priority value that I need. This approach is not convenient.
Ability to adjust this priority through BASS_SetConfig will be very usefull

[Ian @ un4seen]

I use BASS_StreamCreateFileUser to pump data from my own data storage.

Which file system (STREAMFILE_xxx) are you using, and where is the data coming from? Have you confirmed that there is data available to decode when the problem(s) happen, ie. the problem isn't just a lack of data?

Please also try reproducing the problem with local files, eg. BASS_StreamCreateFile.

Yes, its may be overhead for CPU, but I want to experement with it. At this time I use some hack to adjust update thread priority - I wrote some code that searches update thread, gets its thread id, converts ID to HANDLE (in CE are the same) and with using of CeSetThreadPriority sets priority value that I need. This approach is not convenient.
Ability to adjust this priority through BASS_SetConfig will be very usefull

DSP functions run in the update thread, so one fairly simple way you could set its priority is to do so in a DSP function, set via BASS_ChannelSetDSP. DSP functions will also be called during pre-buffering in a BASS_ChannelPlay call, so the BASS_ChannelSetDSP call should be made after starting playback. You can remove the DSP after it has been called once (but not within the DSPPROC itself), as the priority will remain the same for the duration on the thread.

[EEh]

Please also try reproducing the problem with local files, eg. BASS_StreamCreateFile.

I wrote simple test that confirms this problem and sent it to  admin@un4seen.com. Problem is reproduced only if sound output goes through bluetooth headphones (possible because of bluetooth driver latency)