Synccorrente1 = BASS_ChannelSetSync(mixcorrente, bitwise.Bitor(BASS_SYNC_POS,BASS_SYNC_ONETIME),positionToPlayNextTrack, AddressOf aggiungiPlayer2, 0)ĪggiungiPlayer2 is my method, that does more or less the same creating a channel, adding it to the mixer and setting a sync that calls aggiungiPlayer1 Ris = BASS_Mixer_StreamAddChannel(mixcorrente,audiocorrente1,BASS_STREAM_AUTOFREE) Then I create a decoding channel from the file of the first track, add it to the mixer, and set a sync on the mixer to be called when it's time to play the following track ( then current track duration minus, let's say, 4 seconds )Īudiocorrente1 = BASS_StreamCreateFileF(false, audiofile, 0, 0, bitwise.Bitor(BASS_STREAM_PRESCAN, BASS_STREAM_DECODE)) Ris = BASS_ChannelPlay(mixcorrente, false)
#Nicecast pc version mac
Now all this stuff is working fine, both on Mac and Windows ( on Linux I have big segfault problems, but that's another story ) So the two methods aggiungiPlayer1 and aggiungiPlayer2 are identical, playing odd and even tracks of the playlist. It is possible or I should completely rethink the way it works? My question is: how can I make it work all this stuff without a sound card? #WINDOWS EQUIVALENT TO NICECAST MAC# The user reported, that on a 'virtual' machine the connections dropped due to the fact, that the playback is going either slightly too fast or too slow, so that over a period of time a buffer overflow resp. It seems, that this issue is somehow machine related. One of my users reported once something very similar, that the client source connection was disconnected by the server after around 9 days of continuous streaming. This now let me think, that this was basically the same reason!Ī) the one outlined here (constant processing, letting BASSenc do the real time limiting)ī) another one where I did my own real time limiting (checking, the mixer position against the system clock using a CStopWatch) On another (real) machine using a real soundcard he/me could not reproduce the issue. I finally gave up, since I came to the conclusion, that if the system's clock on a virtual machine is running slightly incorrect (resp. different than the one on the streaming server) any real time processing come to a limit, ending in either a buffer overflow or underrun. It is basically, that soundcard clocks are mostly much more accurate and thus it takes comparably longer for the effect to occur. But in the end even that must/will fail after a longer period of time. So to me it sounds, that what the user experienced is totally normal.As I work, throughout the day, music is always playing in the background. Most often, that music is in the form of vinyl spinning on a turntable. But when I’m not in purist mode, I’ll opt to listen to audio by way of a streaming app. Naturally, I’m on the Linux platform, so the only tools I have at my disposal are those that play well on my operating system of choice.
#Nicecast pc version update
Not sure if you saw my UPDate in earlier post but my link is working fine.
#Nicecast pc version software
do you have any old macs laying around ? i just gave my old 3,1 macpro to a friend for a bit so he could run some older software with a Kona 3 card. Now the best way would be to send that Optical output of the Avid I/O to another computer running Nicecast. Then set the Nicecast Input to Digital Input. just need to configure the Avid I/O optical output to be SPDIF and not ADAT. you could take an optical cable out of that into your Mac optical input and pull the audio for nice cast from there.
If my playback engine was built-in audio I'd likely be able to tap into that audio stream from PT, but in a typical session I'd want to use my interface, an Avid I|O.Īvid I/O.
0 kommentar(er)
