Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

PC Based Computer music servers, crossovers, and equalization

PeppyMeter
PeppyMeter
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 30th May 2018, 02:50 PM   #11
rpi is offline rpi  United States
diyAudio Member
 
Join Date: Apr 2015
Location: San Francisco
Quote:
Originally Posted by RAndyB View Post
When I start peppymeter, the meter is showing frenetic activity before any sound program is running. Is that normal?

Your sample asoundrc is valid, but no sound comes from the speakers, and the short piece of music does not finish. Any thoughts?

Would be good if it can be made to work.

Regards,
Andy

The default data source configured in /home/pi/PeppyMeter/config.txt is 'noise'. It's using random volume numbers. This is to make sure that everything required for UI was properly installed/configured. To see the real volume you need to define 'pipe' data source for property 'type' in section [data.source] of the config.txt. Also in the same section you need to define pipe name in property 'pipe.name' (e.g. /home/pi/myfifo).


Which audio player do you use? In most cases you need to start PeppyMeter before starting audio player.


I believe these changes should help if not feel free to ask for help.
  Reply With Quote
Old 30th May 2018, 02:59 PM   #12
rpi is offline rpi  United States
diyAudio Member
 
Join Date: Apr 2015
Location: San Francisco
Quote:
Originally Posted by phofman View Post
Does the peppy script keep reading/flushing the named pipe? If the pipe buffer gets full, I would expect the playback to stop as the popen in file plugin starts waiting on the write operation to the pipe.

You are right, to prevent buffer overflow PeppyMeter should be started before audio player and it should be kept running when audio player is running. If you don't use PeppyMeter the pipe configuration should be excluded from the ALSA configuration.


I found that when you configure pipe output for MPD and don't use ALSA file plugin then MPD handles pipe much better than ALSA plugin. It is not sensitive to buffer underrun/overflow so you can start MPD and PeppyMeter in any order. Also it provides normal signal in both channels.
  Reply With Quote
Old 30th May 2018, 04:48 PM   #13
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
MPD opens the fifo in nonblocking mode MPD/FifoOutputPlugin.cxx at master * MusicPlayerDaemon/MPD * GitHub and keeps checking the write result - if the pipe is full, it drops the samples MPD/FifoOutputPlugin.cxx at master * MusicPlayerDaemon/MPD * GitHub

Whereas alsa file plugin does not specify the nonblocking flag - for both files git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_file.c and pipes git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_file.c . When the pipe is full, the writer gets blocked in the syscall.
  Reply With Quote
Old 30th May 2018, 04:49 PM   #14
RAndyB is offline RAndyB  United Kingdom
diyAudio Member
 
Join Date: May 2005
Location: Herefordshire
Quote:
Originally Posted by rpi View Post
Which audio player do you use? In most cases you need to start PeppyMeter before starting audio player.
I use audacious, configured to use ALSA output.

That output is modified by an extensive .asoundrc file (actually /etc/asound.conf) for crossover and equalisation. ALSA is quite picky about which pcm type can be slave to another pcm. I have been able to make a blue meter work by pretending it is mplayer and setting pipe.size to 8192.

Unfortunately hi-res files seem to defeat it, even with pipe.size set to 32k.

Regards,

Andy
  Reply With Quote
Old 30th May 2018, 05:13 PM   #15
rpi is offline rpi  United States
diyAudio Member
 
Join Date: Apr 2015
Location: San Francisco
Quote:
Originally Posted by phofman View Post
MPD opens the fifo in nonblocking mode MPD/FifoOutputPlugin.cxx at master * MusicPlayerDaemon/MPD * GitHub and keeps checking the write result - if the pipe is full, it drops the samples MPD/FifoOutputPlugin.cxx at master * MusicPlayerDaemon/MPD * GitHub

Whereas alsa file plugin does not specify the nonblocking flag - for both files git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_file.c and pipes git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_file.c . When the pipe is full, the writer gets blocked in the syscall.

Thank you for the detailed info. I think the best way to avoid this kind of issues is to implement new ALSA plugin specific for PeppyMeter. This way it will be possible to have full control on pipe. Something similar to 'ameter' plugin:
ameter
Hopefully it's doable and could be good candidate for the next release.

Quote:
Originally Posted by RAndyB View Post
I use audacious, configured to use ALSA output.

That output is modified by an extensive .asoundrc file (actually /etc/asound.conf) for crossover and equalisation. ALSA is quite picky about which pcm type can be slave to another pcm. I have been able to make a blue meter work by pretending it is mplayer and setting pipe.size to 8192.

Unfortunately hi-res files seem to defeat it, even with pipe.size set to 32k.

Regards,

Andy

Yeah more likely hi-res signal is too much for this Python app. I think only dedicated ALSA plugin could help here. In this case some PCM signal processing could be done in C/C++ in plugin itself and Python could be used just for UI purposes.

Quote:
Originally Posted by RAndyB View Post
...
Unfortunately hi-res files seem to defeat it, even with pipe.size set to 32k.

Andy

You can also try to play with value for 'polling.interval' property. Usually
when you increase pipe size it's better to increase polling interval. For example
try to set it to 0.02. Though I've never used hi-res signal.
  Reply With Quote
Old 30th May 2018, 06:24 PM   #16
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Honestly, I would not spend time developing a specific alsa-lib plugin, the API slowly drifts and if the code is not in upstream, you will end up with non-compilable code eventually.

You can use specialized buffer implementations instead of simple fifo, such as mbuffer.

IMO python should be able to handle processing high res samples, if it can afford processing data in larger chunks - e.g. mbuffer with larger size and reasonably set watermarks.
  Reply With Quote
Old 30th May 2018, 06:37 PM   #17
rpi is offline rpi  United States
diyAudio Member
 
Join Date: Apr 2015
Location: San Francisco
Last time 'ameter' plugin was modified in 2006. I compiled it recently and was able to use without any problems. So, it looks like ALSA is moving very slow.

How can I make audio player output PCM signal to mbuffer?
Thanks!
  Reply With Quote
Old 30th May 2018, 06:55 PM   #18
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Alsa file plugin can pipe to mbuffer using the ! notation. It gives information on format parameters via replacement characters.

I still think a python script with dedicated reader thread should be able to handle high res via regular pipe from the file plugin. It would be started with format parameters to understand the incoming stream (the file plugin closes the pipe when the stream closes) and output the averaged numbers to some continuously running display daemon, also in python. If python did not start fast enough before the pipe fills in and stops the alsa chain, you can always throw mbuffer in between.

The C plugin would have to either compute fast, or use a separate reading thread anyway.

Just my 2 cents, I prefer python to C :-)
  Reply With Quote
Old 30th May 2018, 08:40 PM   #19
rpi is offline rpi  United States
diyAudio Member
 
Join Date: Apr 2015
Location: San Francisco
OK, I'll check if I can leverage that ! notation in Python.

PeppyMeter is doing exactly what you described - it reads data from pipe in separate thread, processes that data and provides it to UI which is running in another thread.

Theoretically PeppyMeter should be able to support hi-res signal as well as it's using Python library 'audioop' which should support signal resolution up to 32 bit:
22.1. audioop — Manipulate raw audio data — Python 3.6.5 documentation

I just never tried that. I'm not sure if I have such files in my collection. Usually some trade-off should be found between pipe size and polling interval.

I also faced some issue with ALSA File plugin - it looks like the signal in right channel has much lower value than the signal in left channel. Maybe it's the question of data format which plugin provides. Probably that's not "pure" PCM signal and has some additional info.
  Reply With Quote
Old 30th May 2018, 09:18 PM   #20
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by rpi View Post
OK, I'll check if I can leverage that ! notation in Python.
You can do it easily, it just runs a command and sends the samples to its stdin via popen ALSA project - the C library reference: PCM (digital audio) plugins The described parameters are replaced in the command name.


Quote:
PeppyMeter is doing exactly what you described - it reads data from pipe in separate thread, processes that data and provides it to UI which is running in another thread.
I understand. But the file plugin starts the process when the alsa device is open and closes popen (which usually results in the process exit) when the device is closed. That would be affecting your GUI process too.

It is good to have the reader started with the new stream as it will always know the actual stream parameters, passed as command line options.



Quote:
Theoretically PeppyMeter should be able to support hi-res signal as well as it's using Python library 'audioop' which should support signal resolution up to 32 bit:
22.1. audioop — Manipulate raw audio data — Python 3.6.5 documentation
Looks very good.

Quote:
I just never tried that. I'm not sure if I have such files in my collection.
You can convert/generate arbitrary format with sox.

Quote:
I also faced some issue with ALSA File plugin - it looks like the signal in right channel has much lower value than the signal in left channel. Maybe it's the question of data format which plugin provides. Probably that's not "pure" PCM signal and has some additional info.
The plugin outputs format which you specify - raw or wav (= raw + wav header). The actual stream format depends on the samples being played and is passed by the plugin to your program via those command-line parameters.

It did work OK when I was testing the addition of the pipe capability to the file plugin git.alsa-project.org Git - alsa-lib.git/commit

I really like your project. I have been watching it closely as this area does interest me ( I few years ago I toyed with Home * pavhofman/plabs-player Wiki * GitHub, some new features are currently WIP... )

Last edited by phofman; 30th May 2018 at 09:34 PM.
  Reply With Quote

Reply


PeppyMeterHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


New To Site? Need Help?

All times are GMT. The time now is 03:10 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.79%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Copyright ©1999-2018 diyAudio
Wiki