Author Topic: BASS for iOS (iPhone/iPad)  (Read 606809 times)

(: JOBnik! :)

  • Posts: 1080
Re: BASS for iOS (iPhone/iPad)
« Reply #975 on: 21 Jan '15 - 22:47 »
Hi ;D

Here's a libbass_fx.a with an updated x86_64 simulator architecture, that should fix a crash in BASS_FX_TempoCreate.
http://www.jobnik.org/files/beta/libbass_fx.a

Let me know if it's fixed now.

Oleg the soundman

  • Posts: 97
Re: BASS for iOS (iPhone/iPad)
« Reply #976 on: 22 Jan '15 - 13:57 »
If you don't have any FIFIO buffer code to hand, it could be implemented with a BASS "push" stream, something like this...

Code: [Select]
fifo=BASS_StreamCreate(1000, 1, BASS_SAMPLE_8BITS|BASS_STREAM_DECODE, STREAMPROC_PUSH, 0); // create mono 8-bit push stream for FIFO buffer

...

void CALLBACK DownloadProc(const void *buffer, DWORD length, void *user)
{
DWORD fifo=(DWORD)user; // push stream handle
if (!buffer) BASS_StreamPutData(fifo, 0, BASS_STREAMPROC_END); // signal EOF
else BASS_StreamPutData(fifo, buffer, length); // write/add data
}

DWORD CALLBACK FileReadProc(void *buffer, DWORD length, void *user)
{
DWORD fifo=(DWORD)user; // push stream handle
while (1) {
DWORD r=BASS_ChannelGetData(fifo, buffer, length); // read/remove data
if (r) return r; // got some data or error/EOF
Sleep(50); // wait for more data to arrive (could use an event instead)
}
}

The BASS headers are the same on all platforms, so you can take them from the Win32/OSX/Linux packages on the BASS webpage.

Ian, taking to account Your suggested FIFO buffer, are there any means to "dispose" a range of data from it? Say, I want to leave just the last 1024 bytes?

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #977 on: 22 Jan '15 - 16:46 »
There are a couple of ways that you can remove data from the push stream's buffer. You can use BASS_ChannelGetData or you can use BASS_ChannelSetPosition (with BASS_POS_DECODETO). The current amount of buffered data is available from BASS_StreamPutData (with length=0). To leave 1024 bytes in the buffer, you would remove the current amount minus 1024...

Code: [Select]
DWORD got=BASS_StreamPutData(fifo, 0, 0); // current buffered amount
if (got>1024) {
QWORD pos=BASS_ChannelGetPosition(fifo, BASS_POS_BYTE); // the current output position/count
BASS_ChannelSetPosition(fifo, pos+got-1024, BASS_POS_BYTE|BASS_POS_DECODETO); // seek to leave 1024 bytes in the buffer
}

Note that if the push stream is being used to buffer file data (like in the post you quoted), then it may be unsafe to remove data from it, as doing that is basically corrupting the file.

Oleg the soundman

  • Posts: 97
Re: BASS for iOS (iPhone/iPad)
« Reply #978 on: 27 Jan '15 - 16:02 »
Ian,

Your example on building level sequence works great for mp3 but doesn't for FLAC or ALAC files, with BASS_StreamCreateFileUSER() returning BASS_ERROR_NOTAVAIL. Looks like it has not enough data to parse the format/stream Are there some additional considerations for these and other plugin-supported formats to work?
« Last Edit: 28 Jan '15 - 08:59 by Oleg N »

Richitst

  • Guest
Re: BASS for iOS (iPhone/iPad)
« Reply #979 on: 27 Jan '15 - 17:07 »
Hi ;D

Here's a libbass_fx.a with an updated x86_64 simulator architecture, that should fix a crash in BASS_FX_TempoCreate.
http://www.jobnik.org/files/beta/libbass_fx.a

Let me know if it's fixed now.

I've tested it and still get the same exc_bad_access problem in BASS_FX_TempoCreate when running x86_64 simulator

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #980 on: 27 Jan '15 - 17:14 »
Your example on building level sequence works like great for mp3 but doesn't for FLAC or ALAC files, with BASS_StreamCreateFileUSER() returning BASS_ERROR_NOTAVAIL. Looks like it has not enough data to parse the format/stream Are there some additional considerations for these and other plugin-supported formats to work?

Is the BASS_ERROR_NOTAVAIL error definitely from BASS_StreamCreateFileUser? As far as I can see, that error code will only be produced if the "No Sound" device is used without the BASS_STREAM_DECODE flag or if the BASS_STREAM_AUTOFREE flag is used with the BASS_STREAM_DECODE flag. That applies to any file format, not only FLAC or ALAC. Are you using the exact same BASS_StreamCreateFileUser call to handle all file formats, or are you doing something different for FLAC/ALAC compared to MP3?

I've tested it and still get the same exc_bad_access problem in BASS_FX_TempoCreate when running x86_64 simulator

Please post the crash log from when using the BASS_FX update.

foritinbras

  • Posts: 6
Re: BASS for iOS (iPhone/iPad)
« Reply #981 on: 28 Jan '15 - 01:25 »
Hi ;D

Here's a libbass_fx.a with an updated x86_64 simulator architecture, that should fix a crash in BASS_FX_TempoCreate.
http://www.jobnik.org/files/beta/libbass_fx.a

Let me know if it's fixed now.

It's crashed on the line 'stream = BASS_FX_TempoCreate(stream, BASS_STREAM_DECODE);' with EXC_BAD_ACCESS.

0x10485c39e:  testq  %rbx, %rbx                  <---- EXC_BAD_ACCESS

The assembly info of the crashed thread:
Code: [Select]
Tiger`BASS_FX_TempoCreate:
0x10485c2ee:  pushq  %rbp
0x10485c2ef:  pushq  %r15
0x10485c2f1:  pushq  %r14
0x10485c2f3:  pushq  %r13
0x10485c2f5:  pushq  %r12
0x10485c2f7:  pushq  %rbx
0x10485c2f8:  subq   $0x28, %rsp
0x10485c2fc:  movl   %esi, %r12d
0x10485c2ff:  movl   %edi, %r15d
0x10485c302:  leaq   0x3e387(%rip), %rax
0x10485c309:  cmpl   $0x0, (%rax)
0x10485c30c:  je     0x10485c327               ; BASS_FX_TempoCreate + 57
0x10485c30e:  leaq   0x3e373(%rip), %rax
0x10485c315:  movq   (%rax), %rax
0x10485c318:  movl   $0x2b, %edi
0x10485c31d:  callq  *(%rax)
0x10485c31f:  xorl   %r14d, %r14d
0x10485c322:  jmp    0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c327:  leaq   (%rsp), %rsi
0x10485c32b:  movl   %r15d, %edi
0x10485c32e:  callq  0x104872931               ; BASS_ChannelGetInfo
0x10485c333:  xorl   %r14d, %r14d
0x10485c336:  testl  %eax, %eax
0x10485c338:  je     0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c33e:  testb  $0x20, 0xa(%rsp)
0x10485c343:  je     0x10485c368               ; BASS_FX_TempoCreate + 122
0x10485c345:  movl   %r15d, %edi
0x10485c348:  callq  0x10485c576               ; ___lldb_unnamed_function254$$Tiger
0x10485c34d:  testq  %rax, %rax
0x10485c350:  je     0x10485c37e               ; BASS_FX_TempoCreate + 144
0x10485c352:  leaq   0x3e32f(%rip), %rax
0x10485c359:  movq   (%rax), %rax
0x10485c35c:  movl   $0xe, %edi
0x10485c361:  callq  *(%rax)
0x10485c363:  jmp    0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c368:  leaq   0x3e319(%rip), %rax
0x10485c36f:  movq   (%rax), %rax
0x10485c372:  movl   $0x26, %edi
0x10485c377:  callq  *(%rax)
0x10485c379:  jmp    0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c37e:  movl   $0x18b0, %edi
0x10485c383:  callq  0x104891206               ; symbol stub for: operator new(unsigned long)
0x10485c388:  movq   %rax, %rbx
0x10485c38b:  movl   %r12d, %ebp
0x10485c38e:  andl   $0xe00, %ebp
0x10485c394:  movq   %rbx, %rdi
0x10485c397:  movl   %ebp, %esi
0x10485c399:  callq  0x10485ad44               ; ___lldb_unnamed_function199$$Tiger
0x10485c39e:  testq  %rbx, %rbx                  <---- Crashed Line EXC_BAD_ACCESS
0x10485c3a1:  je     0x10485c548               ; BASS_FX_TempoCreate + 602
0x10485c3a7:  orl    $0x10000, %ebp
0x10485c3ad:  andl   %r12d, %ebp
0x10485c3b0:  movl   %ebp, 0x74(%rbx)
0x10485c3b3:  leaq   0x3e2ce(%rip), %r13
0x10485c3ba:  movq   (%r13), %rax
0x10485c3be:  andl   $0x3f24009c, %r12d
0x10485c3c5:  movl   $0xc0dbff63, %ebp
0x10485c3ca:  andl   0x8(%rsp), %ebp
0x10485c3ce:  movq   (%rsp), %rdi
0x10485c3d2:  orl    %r12d, %ebp
0x10485c3d5:  movq   %rdi, %rsi
0x10485c3d8:  shrq   $0x20, %rsi
0x10485c3dc:  leaq   -0x463(%rip), %rcx        ; ___lldb_unnamed_function252$$Tiger
0x10485c3e3:  leaq   0x3df66(%rip), %r9
0x10485c3ea:  movl   %ebp, %edx
0x10485c3ec:  movq   %rbx, %r8
0x10485c3ef:  callq  *0x10(%rax)
0x10485c3f2:  movl   %eax, 0x78(%rbx)
0x10485c3f5:  testl  %eax, %eax
0x10485c3f7:  je     0x10485c55b               ; BASS_FX_TempoCreate + 621
0x10485c3fd:  movl   0x8(%rsp), %eax
0x10485c401:  testb  $0x4, %al
0x10485c403:  je     0x10485c41b               ; BASS_FX_TempoCreate + 301
0x10485c405:  andl   $-0x5, %eax
0x10485c408:  movl   %eax, 0x8(%rsp)
0x10485c40c:  movl   %r15d, %edi
0x10485c40f:  xorl   %esi, %esi
0x10485c411:  movl   $0x4, %edx
0x10485c416:  callq  0x104871909               ; BASS_ChannelFlags
0x10485c41b:  movq   0x18(%rsp), %rax
0x10485c420:  movq   0x20(%rsp), %rcx
0x10485c425:  movq   %rcx, 0x60(%rbx)
0x10485c429:  movq   %rax, 0x58(%rbx)
0x10485c42d:  movq   0x10(%rsp), %rax
0x10485c432:  movq   %rax, 0x50(%rbx)
0x10485c436:  movq   (%rsp), %rax
0x10485c43a:  movq   0x8(%rsp), %rcx
0x10485c43f:  movq   %rcx, 0x48(%rbx)
0x10485c443:  movq   %rax, 0x40(%rbx)
0x10485c447:  movl   %ebp, 0x48(%rbx)
0x10485c44a:  movl   %r15d, 0x7c(%rbx)
0x10485c44e:  movq   $0x0, 0x68(%rbx)
0x10485c456:  movl   $0x0, 0x70(%rbx)
0x10485c45d:  movl   (%rsp), %esi
0x10485c460:  movq   %rbx, %rdi
0x10485c463:  callq  0x10485b024               ; ___lldb_unnamed_function214$$Tiger
0x10485c468:  movl   0x4(%rsp), %esi
0x10485c46c:  movq   %rbx, %rdi
0x10485c46f:  callq  0x10485af64               ; ___lldb_unnamed_function205$$Tiger
0x10485c474:  movl   $0x4, %ecx
0x10485c479:  movl   $0x0, 0x84(%rbx)
0x10485c483:  movq   (%rsp), %rax
0x10485c487:  movl   %eax, %edx
0x10485c489:  cvtsi2ssq %rdx, %xmm0
0x10485c48e:  movss  %xmm0, 0x8c(%rbx)
0x10485c496:  movl   $0x0, 0x88(%rbx)
0x10485c4a0:  shrq   $0x20, %rax
0x10485c4a4:  movl   0x8(%rsp), %edx
0x10485c4a8:  testb  $0x1, %dh
0x10485c4ab:  jne    0x10485c4b7               ; BASS_FX_TempoCreate + 457
0x10485c4ad:  andl   $0x1, %edx
0x10485c4b0:  movl   $0x2, %ecx
0x10485c4b5:  subl   %edx, %ecx
0x10485c4b7:  imull  %eax, %ecx
0x10485c4ba:  movl   %ecx, 0x80(%rbx)
0x10485c4c0:  movq   %rbx, %rdi
0x10485c4c3:  xorl   %esi, %esi
0x10485c4c5:  callq  0x10485c25e               ; ___lldb_unnamed_function253$$Tiger
0x10485c4ca:  movl   0x78(%rbx), %edi
0x10485c4cd:  movq   (%r13), %rax
0x10485c4d1:  callq  *0x28(%rax)
0x10485c4d4:  leaq   0x3e1bd(%rip), %rdi
0x10485c4db:  movq   %rax, 0x18a8(%rbx)
0x10485c4e2:  callq  0x10489148e               ; symbol stub for: pthread_mutex_lock
0x10485c4e7:  xorl   %edx, %edx
0x10485c4e9:  movq   0x3e218(%rip), %rax
0x10485c4f0:  movl   0x3e20a(%rip), %ecx
0x10485c4f6:  movq   %rdx, %rbp
0x10485c4f9:  cmpl   %ecx, %ebp
0x10485c4fb:  jge    0x10485c508               ; BASS_FX_TempoCreate + 538
0x10485c4fd:  leaq   0x1(%rbp), %rdx
0x10485c501:  cmpq   $0x0, (%rax,%rbp,8)
0x10485c506:  jne    0x10485c4f6               ; BASS_FX_TempoCreate + 520
0x10485c508:  cmpl   %ebp, %ecx
0x10485c50a:  jne    0x10485c52a               ; BASS_FX_TempoCreate + 572
0x10485c50c:  incl   %ecx
0x10485c50e:  movslq %ecx, %rsi
0x10485c511:  shlq   $0x3, %rsi
0x10485c515:  movq   %rax, %rdi
0x10485c518:  callq  0x1048914ca               ; symbol stub for: realloc
0x10485c51d:  movq   %rax, 0x3e1e4(%rip)
0x10485c524:  incl   0x3e1d6(%rip)
0x10485c52a:  movq   %rbx, (%rax,%rbp,8)
0x10485c52e:  leaq   0x3e163(%rip), %rdi
0x10485c535:  callq  0x10489149a               ; symbol stub for: pthread_mutex_unlock
0x10485c53a:  movq   (%r13), %rax
0x10485c53e:  xorl   %edi, %edi
0x10485c540:  callq  *(%rax)
0x10485c542:  movl   0x78(%rbx), %r14d
0x10485c546:  jmp    0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c548:  leaq   0x3e139(%rip), %rax
0x10485c54f:  movq   (%rax), %rax
0x10485c552:  movl   $0x1, %edi
0x10485c557:  callq  *(%rax)
0x10485c559:  jmp    0x10485c564               ; BASS_FX_TempoCreate + 630
0x10485c55b:  movq   (%rbx), %rax
0x10485c55e:  movq   %rbx, %rdi
0x10485c561:  callq  *0x8(%rax)
0x10485c564:  movl   %r14d, %eax
0x10485c567:  addq   $0x28, %rsp
0x10485c56b:  popq   %rbx
0x10485c56c:  popq   %r12
0x10485c56e:  popq   %r13
0x10485c570:  popq   %r14
0x10485c572:  popq   %r15
0x10485c574:  popq   %rbp
0x10485c575:  retq   


Oleg the soundman

  • Posts: 97
Re: BASS for iOS (iPhone/iPad)
« Reply #982 on: 28 Jan '15 - 09:09 »

Is the BASS_ERROR_NOTAVAIL error definitely from BASS_StreamCreateFileUser? As far as I can see, that error code will only be produced if the "No Sound" device is used without the BASS_STREAM_DECODE flag or if the BASS_STREAM_AUTOFREE flag is used with the BASS_STREAM_DECODE flag. That applies to any file format, not only FLAC or ALAC. Are you using the exact same BASS_StreamCreateFileUser call to handle all file formats, or are you doing something different for FLAC/ALAC compared to MP3?


Ian, my fault. My DownProc is too complicated and it missed some bytes from file header. Strange it worked even on MP3 alone!
Yes, I use one call for all formats. Currently channel is getting created ok but the level sequence not stable - working on it, will tell results here.

P.S. update - got it working. Had to wait till enough data available to get level exactly for 1 s interval.
« Last Edit: 28 Jan '15 - 14:40 by Oleg N »

invoker

  • Posts: 7
Re: BASS for iOS (iPhone/iPad)
« Reply #983 on: 2 Feb '15 - 10:00 »
 www.un4seen.com/stuff/bass_ape-ios.zip
this lib is not support for x86_64,can not debug on mac

how to load bass_ape in

 extern void BASSFLACplugin;
  BASS_PluginLoad(&BASSFLACplugin, 0);
« Last Edit: 2 Feb '15 - 10:38 by invoker »

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #984 on: 2 Feb '15 - 16:04 »
It's crashed on the line 'stream = BASS_FX_TempoCreate(stream, BASS_STREAM_DECODE);' with EXC_BAD_ACCESS.

0x10485c39e:  testq  %rbx, %rbx                  <---- EXC_BAD_ACCESS

I believe the crash is actually somewhere within the preceding "callq" instruction, which is a "new" call. That code appears to be the same as before. I'll check with Arthur what changes were made in the update.

www.un4seen.com/stuff/bass_ape-ios.zip
this lib is not support for x86_64,can not debug on mac

how to load bass_ape in

 extern void BASSFLACplugin;
  BASS_PluginLoad(&BASSFLACplugin, 0);

An updated BASS_APE build that includes the x86_64 simulator architecture is now up in the 1st post. To plug it into BASS_StreamCreateFile/etc, you can do this...

Code: [Select]
extern void BASS_APEplugin;
BASS_PluginLoad(&BASS_APEplugin, 0);

invoker

  • Posts: 7
Re: BASS for iOS (iPhone/iPad)
« Reply #985 on: 3 Feb '15 - 02:26 »
thanks,I gonna try now ;)

invoker

  • Posts: 7
Re: BASS for iOS (iPhone/iPad)
« Reply #986 on: 3 Feb '15 - 06:39 »
It's me again(I'm the very rookie)
I add libtags.a from
 www.un4seen.com/stuff/tags-ios.zip
but there is no header file?
how can I use this libtags.a
still libtags.a not support for x86_64
 :P
ps:where can I get the lastest header file of "base.h"?
Quote
An updated BASS_APE build that includes the x86_64 simulator architecture is now up in the 1st post. To plug it into BASS_StreamCreateFile/etc, you can do this...
this one compile error ,
though it's lipo -info is : Architectures in the fat file: libbass_ape.a are: armv7 armv7s arm64 armv6 i386 x86_64

Quote
Undefined symbols for architecture armv7:
  "APE::GetMMXAvailable()", referenced from:
      l101 in libbass_ape.a(libbass_ape.a-armv7-master.o)
  "APE::FreeAligned(void*)", referenced from:
      l070 in libbass_ape.a(libbass_ape.a-armv7-master.o)
  "APE::AllocateAligned(int, int)", referenced from:
      l068 in libbass_ape.a(libbass_ape.a-armv7-master.o)
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Undefined symbols for architecture arm64:
  "APE::GetMMXAvailable()", referenced from:
      l114 in libbass_ape.a(libbass_ape.a-arm64-master.o)
  "APE::FreeAligned(void*)", referenced from:
      l077 in libbass_ape.a(libbass_ape.a-arm64-master.o)
  "APE::AllocateAligned(int, int)", referenced from:
      l075 in libbass_ape.a(libbass_ape.a-arm64-master.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
« Last Edit: 3 Feb '15 - 07:04 by invoker »

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #987 on: 3 Feb '15 - 16:26 »
Oops! A source file was missing from the BASS_APE build that was posted yesterday; another update to correct that is up in the 1st post now. Updated BASS_MPC and TAGS builds that include the x86_64 simulator architecture are also up, so that all of the libraries in the 1st post should now include x86_64 simulator support.

invoker

  • Posts: 7
Re: BASS for iOS (iPhone/iPad)
« Reply #988 on: 4 Feb '15 - 02:52 »
thanks Ian, and
1.Where can I get the latest header file of "base.h"?
2.Any Usage of libtags.a?Plz help
« Last Edit: 4 Feb '15 - 03:25 by invoker »

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #989 on: 4 Feb '15 - 14:04 »
The BASS and add-on headers are the same on all platforms, so you can take them from the Win32/OSX/Linux packages on the BASS webpage and use them on iOS too. The same goes for the documentation. Also see the "readme" file included in the TAGS add-on package for usage information on that.

invoker

  • Posts: 7
Re: BASS for iOS (iPhone/iPad)
« Reply #990 on: 5 Feb '15 - 02:06 »
thanks again

Richitst

  • Guest
Re: BASS for iOS (iPhone/iPad)
« Reply #991 on: 10 Feb '15 - 19:11 »
It's crashed on the line 'stream = BASS_FX_TempoCreate(stream, BASS_STREAM_DECODE);' with EXC_BAD_ACCESS.

0x10485c39e:  testq  %rbx, %rbx                  <---- EXC_BAD_ACCESS

I believe the crash is actually somewhere within the preceding "callq" instruction, which is a "new" call. That code appears to be the same as before. I'll check with Arthur what changes were made in the update.

Hi Ian. Did you checked the changes in the last update? Still can't use the FX in the IOS simulator.

(: JOBnik! :)

  • Posts: 1080
Re: BASS for iOS (iPhone/iPad)
« Reply #992 on: 11 Feb '15 - 19:26 »
Hi ;D

Another update:
http://www.jobnik.org/files/beta/libbass_fx.a

Let me know if it's fixed now.
« Last Edit: 12 Feb '15 - 08:34 by (: JOBnik! :) »

Oleg the soundman

  • Posts: 97
Re: BASS for iOS (iPhone/iPad)
« Reply #993 on: 12 Feb '15 - 13:10 »
Some libs in 1st post that are not x86_64 ready:
- opus
- wv
(in libbass archive)
Also, are there chances bassmidi.a becomes x86_64?

foritinbras

  • Posts: 6
Re: BASS for iOS (iPhone/iPad)
« Reply #994 on: 13 Feb '15 - 04:46 »
Hi ;D

Another update:
http://www.jobnik.org/files/beta/libbass_fx.a

Let me know if it's fixed now.
I have checked that it works fine. Thanks for your attention.

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #995 on: 13 Feb '15 - 13:55 »
Some libs in 1st post that are not x86_64 ready:
- opus
- wv
(in libbass archive)
Also, are there chances bassmidi.a becomes x86_64?

x86_64 support has now been added to the BASSOPUS and BASSWV libraries in the 1st post. The BASSMIDI library should already include x86_64 support; is it not working for you?

Oleg the soundman

  • Posts: 97
Re: BASS for iOS (iPhone/iPad)
« Reply #996 on: 16 Feb '15 - 09:12 »
Ian, thank You, last time I downloaded the arch libbassmidi.a was not x86_64, now it is. Opus and WV also now link for this arch. Very much appreciation!

ppeau

  • Posts: 48
Re: BASS for iOS (iPhone/iPad)
« Reply #997 on: 17 Feb '15 - 01:30 »
Hey guys,

I need help about getting data from AIFF file with BASS_ChannelGetData. Just like this :

Code: [Select]
   while (BASS_ChannelIsActive(decoder)) {
        size_t c = BASS_ChannelGetData(decoder, buf, sizeof(buf)|BASS_DATA_FLOAT);

        if(c==(DWORD)-1) break;
        memcpy(buffer + pos, buf, c);
        pos += c;
    }

Getting data from M4U, WAV or MP3 works like a charm but AIFF is extremly slow and it is with all the AIFF files.
For the same file in different extension, this is what I get :

WAV : 4.353797 seconds
M4U : 7.684085 seconds
MP3 : 14.341358 seconds
AIFF : 55.107035 seconds ->  :o (Houston we've got a problem!)

Bass_ChannelInfo from AIFF :



My question is : is it normal ???

EDIT :

The stream is also bad, where 500 or 800 ms is quite good for the others extensions, for AIFF, if I modify the tempo rate for example, the sound cut and become very unstable. It is like the AIFF bass's decoder has a lot of trouble to decode in real time or provide data. But with the others is perfect.


Thanks for your help

« Last Edit: 17 Feb '15 - 13:26 by ppeau »

Ian @ un4seen

  • Administrator
  • Posts: 21861
Re: BASS for iOS (iPhone/iPad)
« Reply #998 on: 17 Feb '15 - 18:15 »
From the "ctype" value, that appears to be a tempo stream, ie. created with BASS_FX_TempoCreate. Please remove that (ie. decode the AIFF directly) and see if it is still slow. If it is still slow, also post the new "ctype" value to confirm whether BASS or CoreAudio is decoding the AIFF file.

ppeau

  • Posts: 48
Re: BASS for iOS (iPhone/iPad)
« Reply #999 on: 17 Feb '15 - 18:47 »
My bad, I did not explain where comes from the bassInformation

I 've got two streamCreate.
The first one, is for the main stream and tempo.
The second one, is for my mmap.
Both have the trouble.
The first one : the playback is bad (really bad)
The second is very very slow compare to the others extensions like I explain in my first post.

This one comes from to the BASS_StreamCreateFile for the main stream



This one comes from to the BASS_StreamCreateFile for a simple decoder as I explained in the previous post for my mmap


Thanks for your help.