hi soundcheck,
Most of this info is available already (or will be).
In [Beta] mode, [Main Page] -> [Diagnostics] -> [Raspberry Pi]
Note [Logs] option as well. We usually write log files when people view Diagnostics pages.
[Tweaks] -> [Advanced Overclocking] should show relevant overclocking stuff. (Well it is on mine, I can't remember if all the features are activated in the current release). I have recently done a little more work of overclocking because of the release of the RPi0 and RPi3.
Thanks for keeping us on our toes.
Attachments
Hi soundcheck,
We do not set the speed of the Raspberry Pi's in the default setup.
They should run at whatever speed is "normal" for the RPi board.
If you are playing around with the overclocking page, then yes it has the old overclocking settings. This has been updated but maybe not released yet?
The HMDI power on/off has been implemented, available next release. It downloads rpi-vc.tcz when required. This means it doesn't burden you unless you want the feature.
We try to keep the standard image as small as possible. Remember piCore is ram based, all this stuff is loading into memory on boot. Some of the "unusual" features download the appropriate extension when and if required.
regards
Greg.
I think I found the bug that's causing the (my) confusion.
If I push "None" and "Save" in Overclocking
I end up with this:
BUT:
It should end up like your default settings on the image:
Basically I don't have any way to get back to normal, once I tried any of the overclocking settings.
That's why I thought 700Mhz is default after pushing "None".
I just looked at the default PCP image and figured that you're running default clock settings only on that one.
You might want to check this!
And. Another comment on your overclocking presets.
Even the "Moderate" overclocking preset means not any overclocking on e.g. the PI2.
It's pretty much PI2 default. All other schemes are underclocking on PI2. Obviously this gets worse on a PI3.
This doesn't make any sense.
I think you should really review these overclocking presets. You need a set of presets for each PI revision. -- If you want to stay with presets at all !?!?
Thx
I think I found the bug that's causing the (my) confusion.
If I push "None" and "Save" in Overclocking
I end up with this:
Code:
arm_freq=700
core_freq=250
sdram_freq=400
over_voltage=0
#force_turbo=0
gpu_mem=32BUT:
It should end up like your default settings on the image:
Code:
#arm_freq=
#core_freq=
#sdram_freq=
#over_voltage=
#force_turbo=
#gpu_mem=Basically I don't have any way to get back to normal, once I tried any of the overclocking settings.
That's why I thought 700Mhz is default after pushing "None".
I just looked at the default PCP image and figured that you're running default clock settings only on that one.
You might want to check this!
And. Another comment on your overclocking presets.
Even the "Moderate" overclocking preset means not any overclocking on e.g. the PI2.
It's pretty much PI2 default. All other schemes are underclocking on PI2. Obviously this gets worse on a PI3.
This doesn't make any sense.
I think you should really review these overclocking presets. You need a set of presets for each PI revision. -- If you want to stay with presets at all !?!?
Thx
@ckramer
mmap lets the driver (kernel) and the app (userspace) access the same memory area where the PCM data gets stored before it's send to the device.
Instead of moving data from a->b as done in read/write mode (RW_interleaved) they work with pointers.
MMAP is therefore much more efficient.
However. Depending on maturity of drivers and/or userspace programs there have been reports of corrupted data if running MMAP.
If you feel unsure you can simply turn it off by taking the "1" away from "80:::1"
By running below command - the same you're using - you can tell if mmap is being used:
It'll either say :
access: MMAP_INTERLEAVED
or
access: RW_INTERLEAVED
mmap lets the driver (kernel) and the app (userspace) access the same memory area where the PCM data gets stored before it's send to the device.
Instead of moving data from a->b as done in read/write mode (RW_interleaved) they work with pointers.
MMAP is therefore much more efficient.
However. Depending on maturity of drivers and/or userspace programs there have been reports of corrupted data if running MMAP.
If you feel unsure you can simply turn it off by taking the "1" away from "80:::1"
By running below command - the same you're using - you can tell if mmap is being used:
Code:
cat /proc/asound/card0/pcm0p/sub0/hw_paramsIt'll either say :
access: MMAP_INTERLEAVED
or
access: RW_INTERLEAVED
thanks soundcheck,
The overclocking page has been sorted and updated on 8/5/2016, ready beta testing for the next pCP release. The standard overclocking only works for the RPi Model 1.
For Advanced Overclocking it uses the same options and values as the raspi-config for RPi1 and RPi2. Their are no overclocking options for RPi0 and RPi3.
There is a confusion in raspi-config regarding "None". They define the values and originally used these values, but now they clear the value instead. I originally used both "none" for their defined values and "default" for clearing.
regards
I'm well aware of that raspi-config mess regarding overclocking over the
different PI generations. You simply can't take that as base.
As I said. Beside cleaning up the overclock related flaws in PCP
IMO you either should offer your own PIX related plausible presets
or you better don't offer any presets at all.
Let the users do whatever they want - at their own risk.
The key point is to give the users an option to go back to default.
And to prevent settings that might brick the device.
Would be nice to see default values in real numbers instead of
empty and out-commented fields.
different PI generations. You simply can't take that as base.
As I said. Beside cleaning up the overclock related flaws in PCP
IMO you either should offer your own PIX related plausible presets
or you better don't offer any presets at all.
Let the users do whatever they want - at their own risk.
The key point is to give the users an option to go back to default.
And to prevent settings that might brick the device.
Would be nice to see default values in real numbers instead of
empty and out-commented fields.
Last edited:
6 May 2016 - piCorePlayer 2.05
Please try the new version piCorePlayer 2.05.
The team is happy to release this new version, with special focus on LMS integration and managing attached USB-disk.
Changes:
Please try the new version piCorePlayer 2.05.
The team is happy to release this new version, with special focus on LMS integration and managing attached USB-disk.
Changes:
- Added a LMS-update button, so it is very easy to update LMS to the most recent nightly version.
- Added options to mount hard-disks.
- Added options to move the cache and preferences to mounted drive - otherwise piCorePlayer would be using your SD card, but it might be safer to use a mounted disk.
- Added a pop-up that offers to expand the partition if it is too small.
- Improved the update process, so that it will be future proof if anything changes in pCP.
- Fixed the VU-meter problem.
- A lot of minor improvements throughout the scripts.
18 June 2016 - piCorePlayer 2.06
Please try the new version piCorePlayer 2.06.
This is a bug-fix version. A major part of the underlying code has been rewritten, but the appearance have not changed much.
Changes:
NB: Please notice that you will need to install this version from 2.05. In addition, it is not possible to downgrade to a previous version anymore.
This will probably be the latest release based on kernel 4.1.
We have now started working on a major pCP update based on kernel 4.4 that contains a lot of interesting and important fixes for I2S-audio DACs.
The piCorePlayer Team
Please try the new version piCorePlayer 2.06.
This is a bug-fix version. A major part of the underlying code has been rewritten, but the appearance have not changed much.
Changes:
- piCore updated - where the libstdc++ exception bug is fixed.
- Improved ALSA settings on the Squeezelite page.
- Fixed the issue when trying to move LMS cache to attached Fat based USB disk.
- Improved the update process further.
- Numerous small bug-fixes.
NB: Please notice that you will need to install this version from 2.05. In addition, it is not possible to downgrade to a previous version anymore.
This will probably be the latest release based on kernel 4.1.
We have now started working on a major pCP update based on kernel 4.4 that contains a lot of interesting and important fixes for I2S-audio DACs.
The piCorePlayer Team
Hi Greg.
I tried PcP 3.0 yesterday with the new Mamboberry DAC.
Here are my first issues:
1. There's no "hifiberry-dac" overlay just the "hifiberry-dac+"
I need that for e.g. Sabre es9023 MamboDac and Audiophonics iSabre.
I changed the overlay manually in config.txt. After that it worked.
I dunno if any available other overlay could have been used though.
Wasn't motivated to trace the issue further down after I managed to get
the DAC working - the way it used to work.
2. When configuring the squeezelite buffer (-b) with e.g. 40000:200000 I get format errors.
The GUI won't accept ":200000", just the 40000.
You might check all other fields for similar behavior.
I stopped beta-testing at that point. I might continue at a later stage, probably as soon as I see updates for above coming in.
BTW.
Inmate Clive Messer (clivem) prepared a 4.4.y branch with numerous audio/I2S/dma etc. related patches inside.
There you'll also find explicit overlays for MamboBerry and AudioPhonics iSabre.
IMO the much better kernel choice for an RPI targeted audio distro.
Cheers
I tried PcP 3.0 yesterday with the new Mamboberry DAC.
Here are my first issues:
1. There's no "hifiberry-dac" overlay just the "hifiberry-dac+"
I need that for e.g. Sabre es9023 MamboDac and Audiophonics iSabre.
I changed the overlay manually in config.txt. After that it worked.
I dunno if any available other overlay could have been used though.
Wasn't motivated to trace the issue further down after I managed to get
the DAC working - the way it used to work.
2. When configuring the squeezelite buffer (-b) with e.g. 40000:200000 I get format errors.
The GUI won't accept ":200000", just the 40000.
You might check all other fields for similar behavior.
I stopped beta-testing at that point. I might continue at a later stage, probably as soon as I see updates for above coming in.
BTW.
Inmate Clive Messer (clivem) prepared a 4.4.y branch with numerous audio/I2S/dma etc. related patches inside.
There you'll also find explicit overlays for MamboBerry and AudioPhonics iSabre.
IMO the much better kernel choice for an RPI targeted audio distro.
Cheers
Last edited:
Hi soundcheck,
I think there should be an "I2S: generic" option, which is what I use for ES90023 DACs. We do try to restrict the options depending on the type of Raspberry Pi you have, but if you go into [Beta] mode you will get all the available options. We support all the DAC overlays that are in the current Raspbian distribution once it has flowed into piCore. We do this deliberately to ensure we only get code that has been fully vetted as suitable for distribution under the appropriate licenses. It is very important that the driver really is open source especially when dealing with ESS/Sabre.
We have been adding filters/patterns on inputs in the last few releases. We are trying to reduce the chance of input errors. We can increase the size of this field in the next release. As a work around, you can use the "Various input" field to put in any options you like as this field have no restrictions.
Clive generously helps us, usually in the background, on lots of Raspberry Pi issues, a very valuable resource. We prefer to stick to the official piCore distribution but on the odd occasion a Steen generates a custom kernel. It's a matter of getting things done within the time restrictions we have.
Thanks for your feedback, always interesting
Last edited:
Some more of that "interesting" feedback.
Meanwhile Steen told me that "Generic" I2S actually is the overlay hifiberry-dac. Hmmh.
That hifiberry-dac shows also up as sounddevice when selected "Generic". Hmmh.
and the config.txt gets a - yep - hifiberry-dac entry.
Ok folks. You very well manege to confuse people. That's all not "clean".
I guess you have to work on that one. At least document it.
Meanwhile you can also add parameters to some of the overlays.
Your GUI/mask setup won't allow that. You might look into that too in future releases.
Then I think you set your priorities wrong with all your great efforts. If the most basic stuff and most crucial stuff - the squeezelite parametrization - is not being fully tested and working, you just scare less motivated people off.
You have to be very careful to get the wrong label attached to your project.
Then I'm wondering how Clive can help you, if you stick to standard kernels.
I do have the feeling/opinion though, that you'd better reshuffle your priorities.
The key subject is audio performance.
What's needed for that are kernel/drivers/overlays and squeezelite.
Everything else is nice-to-have.
I for myself don't really need your updates/corrections. I know myself around.
And can fix a lot of stuff myself.
Good luck with your project.
Meanwhile Steen told me that "Generic" I2S actually is the overlay hifiberry-dac. Hmmh.
That hifiberry-dac shows also up as sounddevice when selected "Generic". Hmmh.
and the config.txt gets a - yep - hifiberry-dac entry.
Ok folks. You very well manege to confuse people. That's all not "clean".
I guess you have to work on that one. At least document it.
Meanwhile you can also add parameters to some of the overlays.
Your GUI/mask setup won't allow that. You might look into that too in future releases.
Then I think you set your priorities wrong with all your great efforts. If the most basic stuff and most crucial stuff - the squeezelite parametrization - is not being fully tested and working, you just scare less motivated people off.
You have to be very careful to get the wrong label attached to your project.
Then I'm wondering how Clive can help you, if you stick to standard kernels.
I do have the feeling/opinion though, that you'd better reshuffle your priorities.
The key subject is audio performance.
What's needed for that are kernel/drivers/overlays and squeezelite.
Everything else is nice-to-have.
I for myself don't really need your updates/corrections. I know myself around.
And can fix a lot of stuff myself.
Good luck with your project.
Seems as if v3 has been upgraded.
Too bad a fresh install has to be done.
https://sites.google.com/site/picoreplayer/home/news
Too bad a fresh install has to be done.
https://sites.google.com/site/picoreplayer/home/news
Yep. I did that new install.
To me it still seems pretty unstable. I'm stepping from one issue into another.
I really appreciate the quick solution. However.
You shouldn't just release anything.
They even didn't step the revision number. Hmmh.
I know it's a lot of extra work.
But there are good reasons for stepping Rev numbers in SW design.
To me it still seems pretty unstable. I'm stepping from one issue into another.
I really appreciate the quick solution. However.
You shouldn't just release anything.
They even didn't step the revision number. Hmmh.
I know it's a lot of extra work.
But there are good reasons for stepping Rev numbers in SW design.
Last edited: