Okay !
I didn't know it is possible to set a PA source in the device parameter !
Romain, David : What about adding this to the documentation ?
I can take care of writing a little snippet about this in the
sourcefabric wiki
Thank you Peter !
Le 23/02/2012 20:33, Peter Retep a écrit :
> Hi Martin,
>
> please see the thread below, maybe this helps.
> I use the device parameter to select a PA source.
>
> BR, Peter
>
> ------
>
>
> Hi Romain,
>
> Thanks for your input!
>
> I totally agree, using a filesystem allows a lot of flexibility with a
> range from using mounted external storages up to using distributed web
> storages (like wuala, dropbox, etc) or any other virtual mapping.
>
> Back to the topic itself: I made it using pacmd from pulseaudio-utils.
> paman showed me the way to this.
>
> example without soundcard:
>
> pacmd list-sources | grep name:
> name:<auto_null.monitor>
>
> liquidsoap 'output.file(%mp3, "/tmp/test.mp3"
> ,input.pulseaudio(device="auto_null.monitor") )'
>
>
> example with soundcard:
>
> pacmd list-sources | grep name:
>
> name:<alsa_output.usb-M_Audio_USB_Audio_Quattro-00-Quattro.analog-stereo.monitor>
>
> liquidsoap 'output.file(%mp3, "/tmp/test.mp3"
> ,input.pulseaudio("alsa_output.usb-M_Audio_USB_Audio_Quattro-00-Quattro.analog-stereo.monitor")
>
> )'
>
> the mp3.file contains everything that was played by vlc during the
> recording time.
> So basically this seems to work (I have made no extended tests up to
> now).
>
> Good to know that you can just plug in any sound source to liquidsoap
> by still using pulseaudio monitors!
> Once more this shows to me the advantage of unix philosophy and of
> providing generic interfaces! Thanks for supporting this!
>
> BR, Peter
>
> Am 28.09.2011 01:16, schrieb Romain Beauxis:
>
>> Hi all !
>>
>> I like the idea of a file system -- file systems and file hierarchy
>> always seem more intuitive to people..
>>
>> One idea tho: what about actually running a_virtual_ file system
>> using fuse? You could then map a database and any kind of storage to a
>> fuse-based filesystem. User drops a file, DB is updated and file moved
>> to storage.. Also, all directories are created at once and the
>> structure can be constrained to only have valid path and perhaps files
>> etc..
>>
>> Finally, you can easily map this to another view, for instance a web
>> site..
>>
>> BTW, concerning pulse devices, I think you can use pulse's tools such
>> as paman and the like..
>>
>> Romain
>>
>> 2011/9/27 Peter Retep<[email protected]>:
>>> Hi Damien,
>>>
>>> If a user does not follow the convention, his/her files will not be
>>> played.
>>>
>>> Usually all shows are planned some weeks or days before. We use a
>>> google calendar for planning this.
>>> The calendar synchronisation creates all directories from this and
>>> additionally creates the website entries with all show descriptions.
>>> So mostly user dont need to create any directories, since this is
>>> automatically done if the show is scheduled at the calendar.
>>> So user just needs to drop its mp3 file into the right directory. If
>>> there is a urgent need (e.g. someone has forgotten to schedule the
>>> show)
>>> he sees all existing directories and can use them as template for
>>> the path convention. User does not even has to take care of the file
>>> name or any metatags
>>> (except correct audio duration metadata).
>>> The scheduler writes frequently current and next show to log. So you
>>> can check for errors, before the scheduler (or a cron job) would try
>>> to start a non-existing file.
>>> Additionally I do not want to need the user to care about correct
>>> file paths in the jobs.
>>> All of this should help to prevent misconfiguration or user errors.
>>>
>>> There are multiple reasons why I do not to use a cron job for this:
>>>
>>> - Most users I know, do not know even what a cron job is or what
>>> faults you can do when writing one.
>>> Additionally I would not like a separate cron job for each show
>>> (imagine 24 shows a day, 365 days a year, ok, today we have only
>>> around 10 preproduced shows a week).
>>>
>>> - If there are any changes needed, the user just needs to update
>>> the file system.
>>> So there is no database or any other redundant definition (like
>>> cron) of what is to be played when.
>>>
>>> - Furthermore the scheduler checks frequently if the current
>>> show player is running.
>>> If not, the start of the show will be cutted and played from
>>> the current position.
>>> This is useful for reboots due to power outages and other
>>> outages like process failures. The scheduler would be respawned by
>>> upstart on failure.
>>> Another case like this: the user puts the file at the right
>>> directory still one minute after the show should have been started
>>> (many users I deal with deliver their productions at the last minute
>>> .-)
>>>
>>> As you can see the scheduler does a lot more than still starting a
>>> file at a certain time (e.g. logging, process audits, house keeping,
>>> etc.) to keep everything running
>>>
>>> BR, Peter
>>>
>>> Am 27.09.2011 20:33, schrieb Audiodef Online:
>>>> That looks useful. What if a user doesn't follow the correct dir/file
>>>> structure format? What advantage does this have over using a cronjob?
>>>> Just wondering.
>>>>
>>>> Damien
>>>>
>>>> On 09/27/11 18:03, Peter Retep wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to use the pulseaudio mix channel as input for
>>>>> liquidsoap.
>>>>>
>>>>> Do you know how I can find out the names of available pulseaudio
>>>>> devices?
>>>>> I played around with the names I see at audacity but unfortunately
>>>>> I did not succeed.
>>>>>
>>>>> e.g. the following line will not work, since 'mix' is not the
>>>>> right device name.
>>>>>
>>>>> liquidsoap 'output.file(%mp3, "/tmp/test.mp3"
>>>>> ,input.pulseaudio(device="mix") )'
>>>>>
>>>>> Background:
>>>>>
>>>>> As you might remember we always wanted to have some dynamic
>>>>> scheduler to start a show (a single audio file) at a certain
>>>>> date& time.
>>>>> I have written now a small scheduler which frequently scans all
>>>>> subdirectories below a storage/mnt/storage/ where start date and
>>>>> time is mapped to the path by convention.
>>>>> e.g. if file /mnt/storage/2011/09/27/20-00/show.mp3 exists,
>>>>> show.mp3 will be started at 2011-09-27T20:00:00.
>>>>> Starting a file means starting a cvlc for playout. (At our studio
>>>>> we put the playout audio directly on the sound mixer).
>>>>>
>>>>> Directories are automatically created from our program schedule,
>>>>> so user just has to drop a file in the right folder.
>>>>> To delete or move a show, user can still delete or move the file.
>>>>> The scheduler takes care of file changes, even for shows that are
>>>>> in the past (like a show is inserted to be started a half hour
>>>>> before now).
>>>>> This works good for now and has a very small cpu and memory
>>>>> footprint.
>>>>>
>>>>> Now I would like to build a continous stream with help of
>>>>> liquidsoap to make the scheduler useful for other people, too.
>>>>>
>>>>> Best regards, Peter
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a
>>>>> definitive record of customers, application performance, security
>>>>> threats, fraudulent activity and more. Splunk takes this data and
>>>>> makes
>>>>> sense of it. Business sense. IT sense. Common sense.
>>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>>> _______________________________________________
>>>>> Savonet-users mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a
>>>> definitive record of customers, application performance, security
>>>> threats, fraudulent activity and more. Splunk takes this data and
>>>> makes
>>>> sense of it. Business sense. IT sense. Common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>> _______________________________________________
>>>> Savonet-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> All the data continuously generated in your IT infrastructure
>>> contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Savonet-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>>>
> ------------------------------------------------------------------------------
>
>
> All of the data generated in your IT infrastructure is seriously
> valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Savonet-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/savonet-users
>
>
> Am 23.02.2012 17:51, schrieb Martin Hamant:
>> Hi !
>>
>> Long time no see :)
>>
>> reminder: "PulseAudio clients can send audio to "sinks" and receive
>> audio from "sources"."
>>
>> * In my LS setup, I have multiple dynamic sources - each of them open a
>> connection to the running pulseaudio server (with input.pulseaudio())
>> Then I am using pavucontrol / volume control / Playback tab to route
>> the needed source to each LS's pulse client.
>>
>> * My soundcard provide several sources called
>> 'alsa_input.pci-0000_01_00.0.analog-stereo-chX' ...
>>
>> * pulseaudio remembers each client routing settings, I am not 100% sure
>> how the client identified by PA but it seems each client's settings is
>> associated to the client name. So if I create a input.pulseaudio()
>> source with clientname "test", remove it then create it as 'test' again
>> I will get my routing settings as before.
>>
>> the need: I would like to open explicitly a given PA 'source' from the
>> input.pulseaudio() call, so I would be able to handle routing preference
>> directly from my app.
>> it would remains the following problem: if someone uses pavucontrol to
>> change the routing, my app would not be able to track it. (??)
>>
>> But anyway, that would be a good start to define a default PA source
>> with input.pulseaudio()
>>
>> What do you think ?
>>
>> ------------------------------------------------------------------------------
>>
>>
>> Virtualization& Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Savonet-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>>
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
