Author Topic: A big Thank you and: can i do this (access the single bytes of the stream?)  (Read 605 times)

GUMeyer

  • Posts: 16
Hallo,
at first a big Thank you for BASS.DLL - it is the first "Audio-Access-Interface" that seems to work for me! All other "solutions" got me nothing but errors during compile, during runtime....

But can someone tell me that i can use BASS as a base for the following task: I want to write an LTC-MTC-Synchronizer (LTC is a timecode-format (Longitudinal timecode) used on for example tape-recorders to synchronize them with video and MTC (Midi Timecode) is a timecode to sychronize different midi-"players"). So i need to get the audio signal from an usb-port (named as an audio device) and to access the delivered bytes (the LTC uses Bi-Phase-coding) and to assemble them as timecode information.
The translation into MTC and the output as MIDI is then a task that i have nearly solved respectively i can use other code-fragments (no need for BASS.DLL).
Is BASS suitable for my task?
Many thanks in advance
GUMeyer

EDIT: I want to use Lazarus for this
« Last Edit: 20 Aug '22 - 20:01 by GUMeyer »

Ian @ un4seen

  • Administrator
  • Posts: 24789
When you say "get the audio signal from an usb-port", do you basically want BASS to capture the sound/data from a recording device? If so, that is indeed possible. You would first call BASS_RecordInit to initialize the wanted device and then BASS_RecordStart (optionally with a RECORDPROC callback) to start capturing data. If the wanted device isn't the default recording device then you can first use BASS_RecordGetDeviceInfo to enumerate the available devices. Please see the documentation for details on the mentioned functions. There is also a RECTEST example included in the BASS package that you could have a look at - a Delphi version is included, but if you can read C code then it would be best to check the C version as it is more up-to-date.

GUMeyer

  • Posts: 16
When you say "get the audio signal from an usb-port", do you basically want BASS to capture the sound/data from a recording device?
Well not quite. I want the "byte-data", delivered from the recording (audio) device.

If so, that is indeed possible. You would first call BASS_RecordInit to initialize the wanted device and then BASS_RecordStart (optionally with a RECORDPROC callback) to start capturing data. If the wanted device isn't the default recording device then you can first use BASS_RecordGetDeviceInfo to enumerate the available devices. Please see the documentation for details on the mentioned functions. There is also a RECTEST example included in the BASS package that you could have a look at - a Delphi version is included, but if you can read C code then it would be best to check the C version as it is more up-to-date.
The RECTEST-example i have already found and it gave me a first idea how to proceed. And now, i found the "BASS_ChannelGetData"-procedure and this seems to me to be what i'm looking for. From my understanding this procedure delivers me the bytes  from the ports without any "processing". If this is correct, i plan to combine the RECTEST (which demonstrates me some really usefull solutions) with the LIVESPEC example (that demonstrates me the BASS_ChannelGetData-procedure and how to use it.
If the BASS_ChannelGetData-procedure does not what i expect, which procedure could i then use?
Many thanks in advance
GUMeyer

Ian @ un4seen

  • Administrator
  • Posts: 24789
There are 2 ways to record with BASS: with or without a RECORDPROC callback function provided in the BASS_RecordStart call. If you do provide a RECORDPROC then BASS will push the data to you via that. If you don't provide a RECORDPROC then you can pull the data from BASS via BASS_ChannelGetData. The data is the same in both cases, it's just delivered in a different way. You can also call BASS_ChannelGetData when using a RECORDPROC but note it doesn't remove the returned data from the recording buffer in that case, so it might return some data more than once and other data not at all, depending on the timing of the calls.

If you don't want any processing/resampling then you should request the native sample rate in the BASS_RecordStart call. You can do so by setting freq=0. If you want to check what the current native rate is, you can do so with BASS_RecordGetInfo (see the "freq" value).

GUMeyer

  • Posts: 16
There are 2 ways to record

It is not a recording as normal - i do not want to save the data. And my program could theoretically run nearly infinite - as long as the user has the computer running.

with BASS: with or without a RECORDPROC callback function provided in the BASS_RecordStart call. If you do provide a RECORDPROC then BASS will push the data to you via that. If you don't provide a RECORDPROC then you can pull the data from BASS via BASS_ChannelGetData. The data is the same in both cases, it's just delivered in a different way. You can also call BASS_ChannelGetData when using a RECORDPROC but note it doesn't remove the returned data from the recording buffer in that case, so it might return some data more than once and other data not at all, depending on the timing of the calls.
So, do i understand it correctly: Using a RECORDPROC before BAS_ChannelGetData removes returned data from the recording buffer? (sorry, i'm a bit "fighting" with the online-help because my english language not  being native).

If you don't want any processing/resampling then you should request the native sample rate in the BASS_RecordStart call. You can do so by setting freq=0. If you want to check what the current native rate is, you can do so with BASS_RecordGetInfo (see the "freq" value).
That ist right - i don't want any processing/resampling. I know the current native rate because i have to set it during generation and recording the timecode on the tape.
But thank you though for the hints on the RECORDPROC.
GUMeyer

Ian @ un4seen

  • Administrator
  • Posts: 24789
There are 2 ways to record

It is not a recording as normal - i do not want to save the data. And my program could theoretically run nearly infinite - as long as the user has the computer running.

Yes, but you are still using the recording functions :)

BASS doesn't save the recorded data by default. When wanted, you would need to do that yourself (eg. in a RECORDPROC callback) or use the BASSenc add-on.

with BASS: with or without a RECORDPROC callback function provided in the BASS_RecordStart call. If you do provide a RECORDPROC then BASS will push the data to you via that. If you don't provide a RECORDPROC then you can pull the data from BASS via BASS_ChannelGetData. The data is the same in both cases, it's just delivered in a different way. You can also call BASS_ChannelGetData when using a RECORDPROC but note it doesn't remove the returned data from the recording buffer in that case, so it might return some data more than once and other data not at all, depending on the timing of the calls.
So, do i understand it correctly: Using a RECORDPROC before BAS_ChannelGetData removes returned data from the recording buffer? (sorry, i'm a bit "fighting" with the online-help because my english language not  being native).

When you don't use a RECORDPROC callback, BASS_ChannelGetData will deliver every captured byte exactly once (assuming no buffer overflows). It achieves that by removing the delivered data from the recording buffer, so that it can't be delivered again. BASS_ChannelGetData won't do that when you do use a RECORDPROC callback because the data is delivered via the RECORDPROC, ie. the RECORDPROC (not BASS_ChannelGetData) receives every captured byte exactly once then.

Basically, you need to decide whether you want to pull data from BASS (without RECORDPROC) or have BASS push data to you (with RECORDPROC).

GUMeyer

  • Posts: 16

Yes, but you are still using the recording functions :)
You're perfectly right. :-)

BASS doesn't save the recorded data by default. When wanted, you would need to do that yourself (eg. in a RECORDPROC callback) or use the BASSenc add-on.
I have understood this.

When you don't use a RECORDPROC callback, BASS_ChannelGetData will deliver every captured byte exactly once (assuming no buffer overflows). It achieves that by removing the delivered data from the recording buffer, so that it can't be delivered again. BASS_ChannelGetData won't do that when you do use a RECORDPROC callback because the data is delivered via the RECORDPROC, ie. the RECORDPROC (not BASS_ChannelGetData) receives every captured byte exactly once then.

Basically, you need to decide whether you want to pull data from BASS (without RECORDPROC) or have BASS push data to you (with RECORDPROC).
Thank you for the clarification.
My next step now will be to write a simple (quick and dirty) Testprogram to get the bytes, pushed by BASS (with the RECORDPROC) and to write them into a file. I know what the bytes must contain (the LTC-Format is well documented) and as soon as i recognize a special byte sequence i'm sure i'm on the right way.
Many thanks to you (and also the others for following).
GUMeyer