Hello Ian,

regarding the first tests on bassenc-arm-hf,
i recompiled your "server" test application
and tried with an usb headset.
So i get, at the client end, a glitchy audio,
something like if some samples were missing,
something like if i have a N length buffer but
i miss 1 or 2 samples when i read from it (or write to).
I cannot explain in a better way, but i used this
example because it is the same effect i got when
i was experimenting with the dsp callback and
i was processing the wrong number of samples.
Likewise, the vlc player i'm using, often disconnects
for a while then immediately rebuffers and restart, like
it's consuming data faster than those the encoder can produce.

I tried the mp3 encoder alone from console window,
converting a wav file into an mp3 and it seems ok.
I tried to write the encoded data directly to disc, instead
of streaming them out, tried both mp3 and wav,
and i get the "glitchy" audio on both.
The usb headset was brand new, i didn't know if it could
be defective, so i plugged it into a windows machine and it is ok.
Finally, i copied the same source i'm testing on the arm machine
and recompiled it on a linux-386: using your linux-386
bass and bassenc, all is ok, no glitches, no client disconnecting.

 
Bye
Tom

[edited]
after further investigation, it seems a driver/hardware problem
related to usb stream not being synchronized.
Hoping that someone will fix that.

Great Ian!!!!
I'll try and let you know!

Thanks!

Hi Ian,

is also bassenc planned to be recompiled for arm?

Bye
Tom

Ok,
i'm three times an idiot: 
first because i messed up with the dll
and note that, to be really sure, i downloaded
your dll a second time and copied again to the target system.
Second, because the behaviour of the "new" dll was "strangely"
looking identical to the old one, i made also a crc calculation
of the two files to be absolutely sure that i loaded the new dll.
Third, the new dll solved the problem to fmcoder so i was
trying to understand why he was luckier.

Showing the bass version was enough to understand where the
fault was so, loading the right dll, made everything PERFECT!

Anyway, i did my "homework" and i can tell that this was the
server response when the encoder was down

HTTP/1.0 200 OK
ICY 401 Service Unavailable
icy-notice1:<BR>SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>
icy-notice2:The resource requested is currently unavailable<BR>
HTTP/1.0 200 OK

at the same time, bass_streamcreatefile reported error 5 "error fileopen".

THANK YOU VEEERY MUCH!

When you say "bringing down the encoder", do you mean you disconnect the source from the server but the server is still up?

Yes

And after that, your listener client can never reconnect, ie. BASS_StreamCreateURL always fails?

Yes

And after that, your listener client can never reconnect, ie. BASS_StreamCreateURL always fails? If so, please confirm what error code you get from that call and check what (if any) HTTP/ICY headers are received by using the BASS_STREAM_STATUS flag, something like this..

Many thanks, i'll do all this (i have to contact the customer to access the encoder pc) this night when less listeners are connected,
then i'll report everything.

Ian,
i confirm that the player now always reconnects
if pulling the plug or bringing down the modem
or switching off the router; no problems at all.
Unfortunately, bringing down the encoder
still results in no reconnection, but it will
be successful if i close and reopen the application.

I loaded the dll on a machine running 24/7,
i'll make all vexations i'm used to do to my progs and 'll report.

 
Many many thanks for the moment.


UPDATE 13:40
i had not performed the cable unplugging yet, but i loaded
the new dll on a machine and kept the "standard" dll on another.
I remotely disconnected the encoder and got the same behaviour as before:
-the player cannot reconnect by itself
-closing and opening it or loading the stream url on internet explorer makes it
to connect
-xmplay reconnects once the stream encoder is up again.

 

Just like this:

   FHandle := BASS_StreamCreateURL(
                           PAnsiChar(AnsiString(FFileName))
                          ,FOffsetBegin
                          ,f //flags
                          ,@CallBackStatic.DownloadProc
                          ,self
                          );

i had to pair the channel frequency to the stream samplerate manually, but i disabled this and,
getting the channel attributes, it reports 44100Hz for a 44100 Hz sampled stream (i didn't test with other
samplerates), so it seems that the samplerate is not changed.
I need to finish this quickly to test the program "on air" tomorrow and i'll do deeper tests later.

This is one order of problem, and usually it should be solved before to pass to another problem, but not in this case.
As you are so kind and professional to answer, i would submit another VERY STRANGE thing happened some hours ago,
it's very nice and maybe useful to "harden" your product.

I was playing a stream on the target computer with my program, when the stream stops or there is no connection,
it has to play its internal playlist.
All was ok, then, to make a test, i unplugged the ethernet socket, so it started to play its internal music...all ok.
When i replug the ethernet, it continued to play music and the stream player was reporting BASS_ERROR_FILEOPEN.
Note that on every computer on my network and with my phone i was able to listen the stream correctly (all devices
are connected through the same gateway), the only computer that cannot play the stream was the one i unplugged before.
Nothing changed also rebooting that pc; it was able to play any other url, also an url on the same server but different port,
but in no way it can play the url it was playing before.

A bug in the program? I loaded on that pc a player, based on bass,  i made time ago: same problem! ...every other url ok, that url ERROR_FILEOPEN.
So i downloaded your XMplay and guess...it was able to play the stream correctly!
I tried also another player made with another dll and it was able too.

I contacted the streaming provider guys and they suggested me to add to the url a semicolon at the end

http://myserver:myport/;
 
to start, what they called, an endless stream downloading and this worked !
Then, with them, we tried to open, on that test pc, the streaming url with
internet explorer and it gave a server error indicating ICY not available or something like.

So, what i'm asking for, besides what the server message was, is to understand
why in the same conditions bass would not play that stream while XMplay and
other players did.
Just to guess, is bass doing any sort of handshaking with the server while
the other players don't?
Is this procedure bypassed adding the semicolon at the end of the url?

I'm sorry i cannot give you that url to investigate, because it would be pretty
unuseful, since you would play that url correctly...i should had to send you the "witched" pc.

Many thanks !


Update :
instead of pulling the network plug, i remotely disconnected the streaming encoder which push to the streaming server.
If the disconnection was short, some seconds, all was perfect, i heard just the gap of missing data.
If the disconnection was longer, the buffer got empty, the reconnection loop started and
Bass did not reconnect (ERROR_FILEOPEN) until i opened an internet explorer window pointing to the streaming url,
I started another player sharing the same bass.dll as then main application, and this last
was able to play correctly without having to open internet explorer.

Anyway, starting the second player didn't unlock the main application, just i.e. did the trick.
It seems something socket related: when i connect to the streaming service url with i.e. , did i unlocked something ?
Note that also the main application was able to reconnect, without opening i.e. , if closed and reopened.
Is bass "remembering" something about a failing streaming server that is not freed when i call bass_streamfree?

In the same conditions, Xmplay with just that url in playlist and playlist looped, just passed from "play" to "buffering"
and, when the streamig encoder was restored, started to play again.
Also the other player i have, based on an activex component (i know it is heavily based upon your dll, that's
why i'm trying it in these circumstances), passed from "play" to "buffering" then to "play".

It would be interesting to know what happens in these two conditions and for valid/existent,
i mean that the stream is present and up on the server, not that i'm not connected to the internet at all:
-i'm playing a valid stream, then it goes down and becomes invalid, then it restores and becomes valid again.
-i'm trying to play an invalid/down stream but suddenly it becomes valid.
At the moment it seems that it cannot reconnect in both cases.

The reconnection loop metalanguage for the main application is  something like :

reconnect:
 if handle <> 0 then bass_streamfree (handle);
    handle:=bass_streamcreateurl (....);

if not connected then reconnect.

Hi,

I think, anything you do, the waveform will not be as the original because, and you cannot avoid this, you loose datas.
It is the same problem when you decimate (passing from a high samplerate to a lower samplerate) a waveform: before decimation,
you have to filter out all frequencies in the original file that will not "fit" into the new samplerate, so you will loose datas and the
result will not be any longer similiar  to the original.

I don't know your application but, for what i've seen around on most commercial audio softwares, the very first time a file is loaded,
it takes some more time to be decoded because it is analyzed and a waveform peak file is generated.
In this file you could store the original waveform, decimated at a convenient rate (example you had 1 million points, you save
1000 points).
Before to save the file, you could also decide how to pick the significant points: taking one sample of the original wform out of, say, 1000,
you can decide to store the highest value among the others, so to preserve maximum peaks.
You can then use this for a quick waveform representation of the whole file.
If the user then want to zoom deeply into the waveform, you then could read the datas directly from the file, but in this case you 'll be
fast, because you will not have to decode the whole file but just a small part, that part the user want to see "enlarged".

Bye
drugo

Hello,

i need to receive and convert any incoming stream
to a fixed samplerate and i set up this configuration:

-one bass channel going into a mixer, the mixer sampling rate is set to 48000
-the bass channel connects and plays the url i pass to it.

All is fine, upon activation of the streaming receiver, i plug the channel into
the resampling mixer, but it seems that i have to set the sample rate
of the receiving channel manually because it is playing back the stream,
no matter what the stream sampling rate is, at 48KHz.

To be clearer, if i am playing a 32KHz sampled stream, the channel will run
quickly into stall because it is consuming the incoming datas faster than
the sender can produce and the playback pitch is audibly higher, exactly
1.5 times (48/32) the original.

If the channel is playing alone, without plugging into mixer, all is fine.

Is this normal?
How can i restore the original behaviour of the channel, so i have not
to care about the incoming streaming samplerate?
If i have to change manually the samplerate, where/when is most
correct to do it? (when the streaming info becomes available?)

Many thanks for support.

BASS doesn't handle the downloading of WMA streams itself, so unfortunately the normal buffering options (eg. BASS_CONFIG_NET_BUFFER and BASS_FILEPOS_BUFFER) don't apply, and the BASS_FILEPOS_WMA_BUFFER value is what the Windows Media system reports as its buffering progress.

Yes, i got it...i read it on other threads in the forum.
Just to know, as in other threads it seems that buffer monitoring for wma 'could' be possible,
in my case doesn't work because i have something wrong, like Windows Media System or
other stuff, or it really doesn't work anyway ?
I ask for this, because having a buffer level monitor is important: how can i know if i'm close to stall or how can i
know if the streaming bitrate vs network load/speed is too high so the stream can play but with no continuity?
In this case i would eventually switch to a lower bitrate channel.

Just to be sure, do you mean BASS_CONFIG_NET_TIMEOUT or BASS_CONFIG_NET_READTIMEOUT? The former setting wouldn't come into play once the connection has been made, but the latter would. For example, if BASS_CONFIG_NET_READTIMEOUT is set to 5s and the network cable is unplugged for 6s, then BASS will give up waiting in the meantime.

It was my mistake, i wrote NET_TIMEOUT but really i was meaning BASS_CONFIG_NET_READTIMEOUT.
To be sure, i carried out the test again, changing gateway to an inexistent one and disabling network connection: in this moment  i cannot unplug the newtork cable because i'm on
a wireless network.
I'm using BASS_CONFIG_NET_READTIMEOUT=60000
Anyway, running a Winamp instance with same buffer length and prebuffering settings and my player, on the same pc results in same behaviour:
when i change the gateway ip, if the correct ip is applied within about 20 seconds, it starts filling the buffer again.
If i disable the network connection, in any case, both players will get stalled.  
I'll try later to pull the network cable instead of disabling the net connection.

I meant that you could try playing the same stream in another player on the same system and see if it is affected in the same way when you unplug the network cable, ie. does the player need to reconnect too? That will show us whether what you're seeing is limited to your player/BASS, or if it applies to all players. If it is a matter of the server closing the connection due to a lack of activity, then one would expect that to apply to all players.

Ok so we had seen that Winamp and my player have the same troubles when the network connection has troubles too.
In this case i was looking for this 'extreme' performance, because i have an hardware player and it always fills up the buffer, no matter
what i do.
If the time that i keep the network or the gateway down is less than the buffering time, it will continue to play with no interruption.
Maybe, instead of waiting for data,  it retries to connect when it sees that the network has come back.

Many thanks again for your support !

Many thanks Ian!!

for the first issue it' s all ok now!
The timeout is good, but if i can suggest, maybe it would be
good also to include a command in your interface to abort the connection.
I'll try to follow your suggestion handling directly the prebuffering.

Regarding this particular point, it seems that, while mp3 and aac
are handled correctly, i cannot get the WMA buffering level as,
when i'm playing the wma stream, i read always 100% and
it's not possible: i raised the playback speed until the buffer
got empty and the audio output was intermittent and i always
was reading 100%.
Here's the piece of code used (basswma version 2.4.4.0):

    if (chanFormat = cfWMA) or (chanFormat = cfWMAMP3) then
    begin
      Result := BASS_StreamGetFilePosition(FOwner.FHandle,BASS_FILEPOS_WMA_BUFFER);
    ......


For the second issue, it makes no difference if i set NET_TIMEOUT to 60000mS or 5000mS.
If i disconnect the cable for more than about 5 seconds, the buffer will get empty.
I also tried, as you said, to keep another player running (it's on another machine
but in the same net), but no success also in this case...have i understood what you asked for?
Should i instead have a player on the same machine that i 'll unplug?

Many thanks.

Good morning everybody,

i know it is not a new topic, but i almost going crazy for BASS_StreamCreateURL that,
on some machines, after some while exits, on some others it never does, also after some hours.

I am making a standalone player that should continously play a stream and, if the stream is
down or the player or the host pc is set incorrectly, it should try endlessly to reconnect.
The channel is configured as a decoding channel feeding a nonstop mixer, configured
for a net buffering of 60S and prebuffering 50%, Bass version 2.4.8.1, OS WinXP SP3.

All seems fine, but i got this problem in this way :
when the channel starts buffering but has not filled the buffer yet, i change the
gateway on my PC to a non-existent ip.
In this case, BASS_StreamCreateURL never exits.

The problem is not much that the function never returns, but rather that i cannot
do anything to cancel it.

I also tried what Ian suggests in this topic:

http://www.un4seen.com/forum/?topic=11672.0

but, since  BASS_StreamCreateURL never exits, it doesn't return the handle that
i can then use with  BASS_StreamFree.

Last minute news:
while, with the "Gateway trick", the function never returns even if the gateway
is brought back to the correct one, i noticed that, also after 1 hour or more,
if i unplug the ethernet connector on the "stuck" pc, it immediately
recovers and the function finally returns.
  
Another question: how does bass handle its netbuffer?
While it is playing i tried to unplug the network cable, and i noticed
two different behaviours (netbuffer is 60Seconds).
If, within some seconds, i replug the cable, the audio is not interrupted
and the buffer, once decreasing, fills up again.
If i wait more, say 15 - 20 seconds, then i replug the cable, even if
i can navigate the internet, the buffer does not fill up any more and
after a while the player stops then reconnects.
Why seems that, when the buffer is below a certain level, it
does not grow when the net comes back?



Thanks

Yes Big Gun,

i had already thought to what you suggested but i discarded for these reasons:

-i would have to keep a playback device open without really using it.
-if i set to zero the mixer volume i have nothing to process into the dsp (all values passed are zero)
-if, into the dsp callback, i read all values then i set them to zero, i loose the subsequent level indication at the mixer output.
I should read the peak level into the dsp routine then pass to the level meters; this could be not a serious problem, but i really
dislike to keep the playback device occupied to "play silence".

Maybe i have to set up a thread as MB SOFT said even if i wonder why, having active producers pushing datas into the mixer,
there is no callback to process them when needed.
I don't like much the "polling" approach, i would prefer an event-driven way.

Thanks guys, i'll try something in the next days.

Hello everybody,
i've a problem similiar to that posted here:

http://www.un4seen.com/forum/?topic=699.0

I have some channels, some coming from a webstream, some
coming from the audiocard input.
Each channel has to be resampled so it is passed to a mixer,
then each mixer has its own dsp processing routine.

The dsp is the last part, no audio output is needed.
The "problem" is that i don't need audio output and when i
set the mixer output device as "no sound", the dsp callback is
no longer executed.

I know that when i set the "no audio" device, the mixer becomes a
decoding device, so i have to read the datas using ChannelGetData.

My doubts are:
ok, when i have to read a "static" file (a file on the disk) i can get data
when i want and "digesting" the file in some time so, ok, i'll use channelgetdata.
But in this case, i have always more than an active data producer...both the stream and
the live audio input are continously producing data, so when i have to read them?
In my (maybe wrong) opinion, i think that if there is any producer "pushing" datas,
there should be a callback, an interrupt, something that when a buffer is ready
to be processed, calls the data processing routine.

So, summarizing, what have i to do?

Is any callback available even if the mixer becomes a decoding channel?
Have i to set up a thread which every "N" (how much is N?) milliseconds
calls ChannelGetData and processes the incoming datas, if any?

What else?


Many thanks in advance for any suggestion.

Regards
Tom