next »

[Mike Wittman]

Thanks IAN, your explanation helps alot 

I maintain a list of devices as objects and cross-reference the device numbers between DirectSound & WASAPI by using the device info fields - driver/id (respectively).

I misread the help file on BASS_WASAPI_SetNotify and thought that it would only report on "known" devices and I was trying to look them up by the device number index.  Thereby disregarding a "new" device becasue it wasn't in my list.

I'll rewrite the code to test an "unrecognized" device number with BASS_WASAPI_GetDeviceInfo.

PS:  I found a way to get actual driver information from the Registry (provider, description, version & release date) using the GUID in the driver/id fields.  I believe its undocumented so Microsoft can change the "hive" locations; but its interesting nonetheless.

[Ian @ un4seen]

To make things a bit more convenient (no need to call BASS_WASAPI_GetDeviceInfo to find out whether the device is coming or going), the BASS_WASAPI_NOTIFY_CHANGED notification has now been replaced by BASS_WASAPI_NOTIFY_ENABLED and BASS_WASAPI_NOTIFY_DISABLED notifications. The update is in the 1st post package.

[stevenmmm]

is SPDIF output supported with BASS WASAPI?
It seems a track plays, the fft analysis returns data but no sound is heard and the receiver inidcator shows no signal is being received.
However, all works fine with BASS DirectSound, and WASAPI on this device works with foobar
I tried not using BASS_SAMPLE_FLOAT and also resampling to 48K on the mixer stream but it makes no difference

its the 3rd device in list of WASAPI devices, the first 2 are disabled but i assume i still open it as device number 2
these are the settings reported by BASS for the device:
Digital Output Device (SPDIF) (High Definition Audio Device)    BASS_WASAPI_TYPE_SPDIF,BASS_DEVICE_ENABLED, BASS_DEVICE_DEFAULT

[fmcoder]

Checked with 2 sound cards (optical and coax SPDIF outputs) - everything works...

[stevenmmm]

ian, the person having the problem described above tried out xmplay and had exactly the same behaviour. He then ticked 'Use highest available resolution' and that solved the problem.
I had thought the default in the in the BASSWASPI was to use the highest resolution, so is there anything else xmplay does when that option is ticked?

[Ian @ un4seen]

When the "Use highest available resolution" option is enabled, the XMPlay plugin will first try 32-bit output, then 24-bit, then 16-bit. As you say, that is the same as BASSWASAPI does by default, so it's strange that it would work well in one case and not the other. If you look at XMPlay's "General" info window (press F1), what does the "Output" line say? And if you call BASS_WASAPI_GetInfo in your app, what does that say?

[stevenmmm]

xmplay: "44100 hz - stereo - 16 bit"
my app the same and with these flags: BASS_WASAPI_TYPE_SPDIF,BASS_DEVICE_ENABLED.
The mixer stream is floating-point but i assume bass is converting that to 16 bit (i had previously tried setting the mixer stream to 16bit and it made no difference).
i also changed it so the init call now uses the autoformat flag (before i was using the basswasapi function to check if the source file format was supported and falling back to the shared mode format settings). Its returning no error as before.
this person also just connected analog output and that works fine through the speakers device, so its only SPDIF output

[Ian @ un4seen]

xmplay: "44100 hz - stereo - 16 bit"
my app the same and with these flags: BASS_WASAPI_TYPE_SPDIF,BASS_DEVICE_ENABLED.

Just to be sure, are you using BASS_WASAPI_GetInfo or BASS_WASAPI_GetDeviceInfo? I ask as those flags are BASS_WASAPI_GetDeviceInfo things, while it is BASS_WASAPI_GetInfo that tells the sample format currently being used (in the BASS_WASAPI_INFO structure's freq/chans/format members). If that shows no difference to XMPlay, I'll probably have to send you a debug version to get some further info.

[stevenmmm]

buff=180224,chans=2,freq=44100,format=BASS_WASAPI_FORMAT_32BIT,volmax=0,volmin=-1019215872,volstep=1069547520,initflags=BASS_WASAPI_EXCLUSIVE, BASS_WASAPI_AUTOFORMAT

i guess the problem is the 32 bit format?

[Ian @ un4seen]

Yep, that does appear to be the only difference compared to the XMPlay output. The puzzling thing is that the XMPlay plugin will also try 32-bit before 16-bit when the "Use highest available resolution" option is enabled; are you sure the user didn't actually disable that option to get it working in XMPlay? If that option is enabled, I think I will have to send you debug versions of BASSWASAPI and the XMPlay plugin to see what's happening differently in them.

[stevenmmm]

sorry - i misread this persons response and infact he had to turn off the option in xmplay.
perhaps a similar option could be provided in basswasapi? (isnt SPDIF always 16bit or at least would always work with 16 bit?)

[Mike Wittman]

FYI:

I'm not really following the WMPlay stuff but just for clarification;  SPDIF is 24 bit or less... Technically it's 2 channel max with frequencies from 44.1 (or lower) to 192KHz.

There are however encoding techniques to produce multi-channel sound as well as 32bit resolution thru SPDIF ( a pass thru system, where the data isn't simple PCM values ), but the audio equipment has to be compatible to lock onto these signals.

 

[Mike Wittman]

PS:

On a PC you can in fact configure the Mixer ouput (Vista+) to use an "extended" SPDIF formats by default; which could cause problems from BASS WASAPI Exclusive if the audio equipment is not expecting one of these "high-end" SPDIF formats.

In some cases then, "Windows" sound might work fine but BASS may not because it is trying to use the highest bit resolution of the soundcard.

On the other hand; my "reciever" won't do 96KHz at bit resolutions over 16.  Yet I could configure Windows for 96 KHz/24bit.  It took me quite a while to sort this problem out until I had the brainstorm to check the receiver spec's !

 

[stevenmmm]

another person is also having the same problem with SPDIF. This link shows the settings he uses with JRiver to get the device to work with that app:
http://www.thewelltemperedcomputer.com/SW/Players/MC14/MC_Wasapi.htm
I noticed he has an option: "present 24-bit data in a 32-bit package" ticked

Also when this person plays output to a USB device using WASAPI my app crashes (I assume on the device initialise call).
I havent looked into this but just thought i would mention it in case USB devices arent supported by BASS_WASAPI?

[Mike Wittman]

I have two USB soundcards (one I designed myself) that ONLY use SPDIF connections.  BASS WASAPI works beautifully on both of these devices !

How old are your drivers ?

Up until Vista SP1 the "full" usbaudio.sys specification was NOT supported by Windows.  Hence the drivers for USB audio often suffered from implementation difficiencies which could explain why the driver behaves erratically.  It's possible that BASS WASAPI is not getting sufficient or valid device information from the O/S.

For instance; very few USB audio drivers explicitly declare all their bit rates and resolutions or do it according to "spec".  It's complicated and takes quite a bit of work to do correctly and there's not alot of examples.  I often see device driver coders using other manufacturers' code and not take the time to actually test how they behave.

PS:  I know of only a few USB audio devices that use the USB Isochronous/Asynchronous protocol.  Which is the ONLY USB protocol that will allow "bit-perfect" music to be rendered thru WASAPI.

[Ian @ un4seen]

On a PC you can in fact configure the Mixer ouput (Vista+) to use an "extended" SPDIF formats by default; which could cause problems from BASS WASAPI Exclusive if the audio equipment is not expecting one of these "high-end" SPDIF formats.

In some cases then, "Windows" sound might work fine but BASS may not because it is trying to use the highest bit resolution of the soundcard.

On the other hand; my "reciever" won't do 96KHz at bit resolutions over 16.  Yet I could configure Windows for 96 KHz/24bit.  It took me quite a while to sort this problem out until I had the brainstorm to check the receiver spec's !

That's a good point. So there probably needs to be a way for the user to specify/limit the resolution to use in BASS_WASAPI_Init/CheckFormat, in case the receiver doesn't support what the soundcard is giving it by default; an update including that ability is now in the BASSWASAPI package (see 1st post). Please report any problems with it.

another person is also having the same problem with SPDIF. This link shows the settings he uses with JRiver to get the device to work with that app:
http://www.thewelltemperedcomputer.com/SW/Players/MC14/MC_Wasapi.htm
I noticed he has an option: "present 24-bit data in a 32-bit package" ticked

Yep, some devices/drivers require 24-bit data to be padded to 32-bit while others require no padding, so BASSWASAPI will try both with and without padding. I'll send you a debug version to send to both users, to confirm what the drivers are reporting.

Also when this person plays output to a USB device using WASAPI my app crashes (I assume on the device initialise call).
I havent looked into this but just thought i would mention it in case USB devices arent supported by BASS_WASAPI?

USB devices in general should be fine, but it sounds like there could be a problem with that particular device. Please send the debug version to that user too, to narrow down where the problem lies.

[firemen]

pleas delphi samples

[firemen]

tell me please, why created empty mp3 file 625 bytes?

procedure StopRecord;
begin
  BASS_Encode_Stop(instream);
  BASS_StreamFree(instream);
  BASS_WASAPI_SetDevice(indev);
  BASS_WASAPI_Stop(TRUE);
end;

procedure StartRecord;
begin
  BASS_WASAPI_GetInfo(wi);
  BASS_StreamFree(instream);
  instream:= BASS_StreamCreate(wi.freq, wi.chans, BASS_SAMPLE_FLOAT or BASS_STREAM_DECODE, nil, 0);
  instream:=  BASS_Encode_Start(instream, lameparam, BASS_ENCODE_AUTOFREE, nil, 0);
  BASS_WASAPI_SetDevice(indev);
  BASS_WASAPI_Start();
end;

function InWasapiProc(buffer: Pointer; len: DWord; user: Pointer): DWord;
begin
  BASS_ChannelGetData(instream, buffer, len);
  result:= 1;
end;

procedure TRecordForm.SetInputDevice(id: Integer);
begin
  inDev:= id;
  BASS_WASAPI_Init(indev, 0, 0, 0, 1, 0.1, @InWasapiProc, nil);
end;

[Ian @ un4seen]

That code looks fine except that the WASAPIPROC should use the "stdcall" calling convention, so you could try this little modification...

function InWasapiProc(buffer: Pointer; len: DWord; user: Pointer): DWord; stdcall;

[firemen]

I'm probably somewhere did not understand until the end .. all the same mp3 file is empty..
wma file is in the record, but when you play only hear noise

const

  lameparam = 'lame.exe --alt-preset standard - bass.mp3';

var
  RecordForm: TRecordForm;

  inDev, IsEnc: Integer;

  wi: BASS_WASAPI_INFO;
  di: BASS_WASAPI_DEVICEINFO;

  instream: HStream;


implementation

{$R *.dfm}

procedure StopRecord;
begin
  BASS_Encode_Stop(instream);

  BASS_WMA_EncodeClose(IsEnc);

BASS_WASAPI_SetDevice(indev);
BASS_WASAPI_Stop(TRUE);
end;

procedure StartRecord;
begin
  // lame mp3
  instream:=  BASS_Encode_Start(instream, PChar(lameparam), BASS_ENCODE_AUTOFREE, nil, 0);

  // wma
  BASS_WASAPI_GetInfo(wi);
  IsEnc := BASS_WMA_EncodeOpenFile(wi.freq, wi.chans, 0, 128000, PChar('test.wma'));
  BASS_WMA_EncodeSetTag(IsEnc, Nil, Nil, BASS_WMA_TAG_ANSI);


  BASS_WASAPI_SetDevice(indev);
  BASS_WASAPI_Start();

end;

function InWasapiProc(buffer: Pointer; len: DWord; user: Pointer): DWord; stdcall;
begin

  BASS_WMA_EncodeWrite(IsEnc, buffer, len);  // wma
  BASS_ChannelGetData(instream, buffer, len);  // mp3
  RecordForm.caption:= TimeToStr(time);

  result:= 1;
end;

procedure TRecordForm.SetInputDevice(id: Integer);
begin
  inDev:= id;
  BASS_WASAPI_SetDevice(indev);
  BASS_WASAPI_Stop(true);
if (BASS_WASAPI_Init(indev, 0, 0, 0, 1, 0.1, @InWasapiProc, nil)) then begin
      BASS_WASAPI_GetInfo(wi);
      BASS_StreamFree(instream);
      instream:= BASS_StreamCreate(wi.freq, wi.chans, BASS_SAMPLE_FLOAT or BASS_STREAM_DECODE, nil, 0);
end else ShowMessage('Not Init WASAPI');

end;

procedure TRecordForm.Timer1Timer(Sender: TObject);
var
  level: Float;
begin
  if BASS_WASAPI_IsStarted() then begin
     level:= BASS_WASAPI_GetDeviceLevel(indev,-1);
     Label2.Caption:= FloatToStr(level);
  end;

end;

procedure TRecordForm.Button1Click(Sender: TObject);
begin
  StartRecord;
end;

procedure TRecordForm.Button2Click(Sender: TObject);
begin
  StopRecord;
end;

procedure TRecordForm.DeviceComboBoxChange(Sender: TObject);
var
  i: Integer;
begin
  if DeviceComboBox.ItemIndex < 0 then exit;
  i:= system.Pos('=', DeviceComboBox.Items[DeviceComboBox.ItemIndex]);
  if i > 0 then begin
    i:= StrToIntDef(Trim(system.Copy(DeviceComboBox.Items[DeviceComboBox.ItemIndex] , 1, i -1)), -2);
    SetInputDevice(i);
  end;
end;

procedure TRecordForm.FormCreate(Sender: TObject);
var
  i: Integer;
  s: String;
begin

   BASS_SetConfig(BASS_CONFIG_UPDATETHREADS, 0);
  BASS_Init(0, 44100, 0, 0, nil);

   instream:= 0;
   i:= 0; DeviceComboBox.Items.Clear;
   while BASS_WASAPI_GetDeviceInfo(i, di) do begin
      if ((di.flags and BASS_DEVICE_INPUT > 0) and (di.flags and BASS_DEVICE_ENABLED > 0)) then begin
         s:= IntToStr(i)+' = '+di.name;
         DeviceComboBox.Items.Add(s);
         if ( (di.flags and BASS_DEVICE_DEFAULT) > 0) then  SetInputDevice(i);
      end;

      inc(i);
   end;

   Timer1.Enabled:= true;

end;

procedure TRecordForm.FormDestroy(Sender: TObject);
begin
while BASS_WASAPI_Free() do Application.ProcessMessages;
  BASS_Free();
end;

end.