tnxxxxxxxxxxxxx

a solution...

http://forum.sourcefabric.org/discussion/15027/simple-way-for-recording-streams/p1


And, yes, I'm back from holidays ;-)

I'm agree with you, but for now it is a solution
that's a feature asked since a long time ago...

it's only not implemented yet
but recording a show is not mandatory
a stream (from master or show source) recorded  will be for some of us a real great feature (for replay)
perhaps available on 2.5 or 2.6...

Nat Persaud said:

Right now Airtime can record from the line input. It can also schedule playback to the line output. Those capabilities are present and fully implemented. However, it seems like an extra check has been put in place to not allow both to occur at the same time. The manual mentions that you cannot do both with no explanation as to why. Is there some technical problem with doing both?

I think it has to do with eca, not with liquidsoap. But that's just speculation.

Generally I was also expecting a different behaviour than Record&Rebroadcast currently works.
We did have a lot of discussions about this, just to tease a little.
http://forum.sourcefabric.org/discussion/11050/live-show-from-line-input-not-streaming/p1
http://forum.sourcefabric.org/discussion/15251/line-in/p1
http://forum.sourcefabric.org/discussion/15583/line-in-as-a-live-source/p1

As we run Airtime at an FM-Radio Station with local Live-Studio, I am still a big supporter of Mulitple-Line-Inputs.
For me it's essential for near future!
Next
week I try to encourage a few devs from a friendly RadioStation near
ours, to also jump on Airtime and help developing Live-Line-In-Support.
They won't jump on Airtime without this feature.

I will demo our Showcase during the next hangout. But Nat, you already know my setup...

The original use case for the current recording feature was an FM station that was not streaming via Airtime, rather using it as a timed recording/playback system. It uses the default ALSA device, which potentially blocks the use of this device for a simultaneous stream input (unless a sound server or ALSA plugin is used).

There are three ways I can think of improving the situation...

1. Have an ALSA plugin split the hardware input into two virtual devices, one to be used by Liquidsoap for pass-through streaming and the other for the recorder process

This offers a potential solution but it is hard to guess what kind of soundcard the user has (if any), and which ALSA options are available for it, so it may be hard to auto-configure. Also it does not help record shows that are generated from the Library.

2. Have the recorder use a stream ripper on the output, and leave the hardware input free for pass-through streaming

It may seem strange to create a stream for a station which is not streaming to the Internet, just so that shows can be recorded, but we probably want to do lossy compression anyway (to keep the disc space required for the recordings reasonable).

Possibly you would want to use a higher bitrate for the stream meant for ripping, or even stream in FLAC for recorder use only (i.e. a lossless stream which you might not advertise to the public). 

3. Make a small change to the recorder script so that it uses the
ALSA device specified in a configuration file, rather than the default
device

This is very easy to do but it requires multiple ALSA devices or one multi-channel device plus some external routing, such as a mixer. Like option 1, it does not help record shows that are generated from the Library.

So personally I favour option 2, using a stream ripper instead of Ecasound, even when that stream is on the localhost only. It would mean removing the prohibition on adding content to shows set for recording. Also we could use more of the metadata from the show to tag the recording better.

I like the suggestion of having a global recording preference so that the user does not have to specify each show for recording. We would probably need a preference such as 'Delete recorded shows after x days' to prevent disks filling up.

Albert FR said:

I'm totally agree with you @daniel :D
Point 2 is the solution for everybody

Would it be possible in case 2 to use multiple Inputs?
For sure not simultanously, but just to be able to connect two or more studios to Airtime-Server-Soundcard. (M-Audio 1010 in our case)

For me 320kbps-mp3-files would last for Recordings. Being able to use WAV or FLAC would be cool but not essential.

The "Delete Recordings after X Days"-Feature would be nice.
I already ticketed a similar request for files http://dev.sourcefabric.org/browse/CC-5304

Thanks for the perspective @Daniel.

I think for internet radio users, who are essentially using Airtime for what it was made for, this whole recording issue gets solved by a stream-ripper that can be scheduled by the calendar.

For FM users, Airtime can be set up in different positions in the analog chain. It can be before the mixer (my case) or after the mixer (Hoerich's case). In either case, program audio (the final mix) needs to get to the recording.

Pre-mixer
Airtime is used as a recorder and program audio from the mixer comes in through the analog input, so we just schedule the recording via the calendar. Since Airtime is pre-mixer, scheduled content in Airtime will be played at some point through the mixer and this needs to be recorded too, so we can't restrict recording for only no-content shows. I am assuming that Airtime would be able to able to use the ALSA input and output devices simultaneously without any ALSA plugins or configuration files.

Post-mixer
Program audio is at the output of Airtime. The solution is the same as the internet radio case. The Airtime input in this case is not used because, currently, you can't play through.

@Daniel, which case was assumed when the record feature was added?

Is it not trivial to solve the Pre-mixer case?

There are several factors affecting the decision to go pre or post mixer. It could be a whole other discussion and maybe it is relevant to this. An important goal is to have only one schedule that drives everything.

@hoerich, why do you want the line input to be recorded? Don't you want Airtime's output to be recorded instead?

Nat Persaud said:

@hoerich, why do you want the line input to be recorded? Don't you want Airtime's output to be recorded instead?

I'm hoping for a Record-per-Show-Function.
No matter where to touch the record. Technically it seems that it has to be done on the output.

My wish for Record&Rebroadcast-Enhancements:
Live-Broadcast & simultaneously record each Show from Line-Input with the ability to automatically schedule repeat(s) of the recording file.

A 24/7-Record is secondary for our Station.

We use the Airtime.Pro SaaS platform for our virtual radio station - Dakota Music Collective. Its a collection of 100% local/regional original music from the Dakota area in the US.  We are a nonprofit organization called Community Radio Group Broadcasting.  Website is www.crgb.us, and we have an Android App called Dakota Music Collective - hope you will check it out!

SOX   http://sox.sourceforge.net/  for all your recording and audio processing and it can be scripted easily.

Butt can be used for live and show recording

Hi Nat, in the original recorder design, Airtime was more like a Tivo, being used to time-shift shows. It would use an aux send from the mixer to capture live content, and play it out to an aux return as a repeat show when the studio was unstaffed. There was no simultaneous capture and playout, so there were no issues with full duplex use of soundcards.

Albert, thanks for your response. The Tivo idea clarifies a lot. Please
note that I did not get that sense from reading the manual.
In my case shows are typically live. But, I want to have the
flexibility of doing scheduled play or streaming using the exact same
schedule. For example, if a programmer can't make it one week or if they want to
do a remote live to air, they should be able to do that at will without
changing the schedule. In parallel, I want all shows to be podcasted
automatically, which just means recording and tagging.

Daniel James said:

In the proposed redesign of the recorder, we will probably need a recommended list of audio hardware if we rely on full duplex use. Liquidsoap can do full-duplex without a buffer (see the last example here: http://savonet.sourceforge.net/doc-svn/cookbook.html) but of course this is not strictly necessary if you have a mixer - you would just send the live audio direct to the transmitter, without latency.

I'm not sure what you mean here. Can you comment on the question of pre or post mixer and which you are assuming? I think this is a critical point.

Daniel James said:

Even so, I would suggest that in an FM scenario, the recorder uses the stream output, rather than the ALSA device. This is because Liquidsoap has already done the CPU work of compressing the stream data, so we don't need to do that a second time in the recorder program. Even if there is no Internet, Airtime uses Icecast for browser-based monitoring (the Listen button), so the whole system could run on localhost if necessary.

Agreed.

Daniel James said:

Lately I have been experimenting with icecream, a simple Perl script that takes an output stream and saves it as files, based on various parameters including time in minutes: http://packages.debian.org/en/stable/amd64/net/icecream

Possibly we could reimplement the features of icecream that we need in Python, or just use it directly. The implication is that we need a fallback at the Icecast level to make sure the stream does not ever die (killing the recorder process), e.g. when a Liquidsoap parameter is changed and Liquidsoap is restarted. Happily, that would also help ensure that the listening public does not get disconnected either, so it's a win-win.

Well I think it's fine to record what the audience heard even if it cut out, but you have a solution so good. It is vitally important that the user need only define the schedule once, not separately for record and playback.