July 2018 - Sound-open-firmware - mailman.alsa-project.org

[Sound-open-firmware] Mixer doubts
by slawomir.blauciak＠linux.intel.com 23 Jul '18

23 Jul '18

Hello, everyone. I’ve been reading through the mixer code and there’s one part which leaves me somewhat doubtful: /* mix N PCM source streams to one sink stream */ static void mix_n(struct comp_dev *dev, struct comp_buffer *sink, struct comp_buffer **sources, uint32_t num_sources, uint32_t frames) { int32_t *src; int32_t *dest = sink->w_ptr; int32_t count; int64_t val[2]; int i; int j; count = frames * dev->params.channels; for (i = 0; i < count; i += 2) { val[0] = 0; val[1] = 0; for (j = 0; j < num_sources; j++) { src = sources[j]->r_ptr; /* TODO: clamp */ val[0] += src[i]; val[1] += src[i + 1]; } /* TODO: best place for attenuation ? */ dest[i] = (val[0] >> (num_sources >> 1)); dest[i + 1] = (val[1] >> (num_sources >> 1)); } } More specifically: dest[i] = (val[0] >> (num_sources >> 1)); dest[i + 1] = (val[1] >> (num_sources >> 1)); Going back in the history of the file I found it was supposed to be an average. However, it will only be an average if num_sources is power of 2, because otherwise such bitwise operations will yield different results from what I take should be an optimized way for division. For example, suppose we have 2 cases: • We have 2 sources, thus num_sources >> 1 will equal 1, valid right bitshift, same as division by the number of sources, which is 2 • We have 3 sources, thus num_sources >> 1 will equal 1 once again, no longer valid, because it will yield the same result as division by 2, instead of 3. There’s one more “problem”, by averaging the samples like that we will end up with quieter output for when we have 1 source completely silent. Is that intentional? Whether it’s all deliberate or not, or simply whether I misunderstood the code, I hope you can help me clear this up. Thank you, Sławomir Błauciak

4 5

[Sound-open-firmware] the SOF state machine issue
by zhigangw 18 Jul '18

18 Jul '18

Hello All: I analysis the state machine of the SOF, and find something incorrect. I attached the diagram in this email. In this diagram, I only draw the correct flow, the incorrect part I did not draw it, if not, It will cause this picture too complicated. there are four states: ACTIVITY, PREPARE, READY, PAUSED in this state machine. between each state, there are several arrows, which represents the command. Notes: the red arrow and word is added by myself. The problem is: 1. When the component stays at "PREPARE", if the "PAUSE" command comes, it will return error. When the XRUN happens, the recover process will set the component in this pipeline in "PREPARE" state, At this time, the "PAUSE" command comes, which will cause this issue. 2. When the component stays at "PREPARE", the "RELEASE" command would also comes. Solution: 1. This is the first proposal: I add the red arrow and word to display my solution. When the "PAUSE" command comes, the state transfers from "PREPARE" to "PAUSED". When the "RELEASE" command comes, the state transfers from "PREPARE" to "ACTIVITY". 2. This is the second proposal: Make the "pipeline_xrun_recover()" function atomic, which might avoid this kind of issue. But which would have long latency. Thanks ~Zhigang

2 3

[Sound-open-firmware] [RFC PATCH 0/6] Cleanups for SSP slave support on APL/CNL
by Pierre-Louis Bossart 17 Jul '18

17 Jul '18

While looking at the settings needed for the SSP slave support, I came across severial confusions or errors. I still can't get this mode to work but I could use feedback on the following patches, and also double-check if there is any impact in master mode. Comments/test welcome. Pierre-Louis Bossart (6): apl-ssp: fix SSIOC_SCOE apl-ssp: fix SSIOC_SFCR apl-ssp: fix SCR1_SCFR apl-ssp: move SSCR0_ACS,MOD as default settings apl-ssp: fix SSCR0_ECS apl-ssp: fix SSCR1_SFRMDIR src/drivers/apl-ssp.c | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) -- 2.14.1

1 6

[Sound-open-firmware] code stabilization
by Pierre-Louis Bossart 13 Jul '18

13 Jul '18

Hi, Since there's been a lot of churn and issues this week, I thought I would share what works for me in a simple setup (Up^2 board with Hifiberry DAC+/PCM512x). The commits below seem to work decently, without the usual topology load failures, IPC timeouts or corrupted sound that were reported by others. It would be nice if others could try and reproduce those results and try on different APL/CNL boards with the xt-xcc compiler. Don't try on Baytrail/Cherrytrail/Broadwell for now until the GCC compilations issues are fixed. I would recommend we stop merging new features or fixes for corner cases to reach our goal of a stable release in the coming days, or push them to -next while we deal with those annoying first-order issues. Thanks -Pierre Kernel (2 branches maintained) topic/sof-v4.14 commit cae4773bbd83 ('ASoC: SOF: apply IPC changes to byt') topic/sof-dev (4.17) commit a3a39f21218c ('Merge pull request #28 from RanderWang/ipx_fix') SOF master commit 295d0c131c79 ('Merge pull request #81 from tlauda/topic/volume_processing') SOFT master commit 2abbfc0910c ('Merge pull request #28 from plbossart/debug/pcm512x')

1 0

[Sound-open-firmware] [RFC PATCH 0/2] GLK/APL topology edits
by Pierre-Louis Bossart 12 Jul '18

12 Jul '18

Posting this to the mailing list so that its archived and searchable. Basically I am trying to modify the GLK topology to support the ApolloLake Chromebooks. It's only a matter of swapping two SSPs but the changes in the topology files are far from trivial. Feedback welcome. Pierre-Louis Bossart (2): topology: simplify sof-glk-codec.m4 topology: add sof-apl-da7219 support topology/Makefile.am | 1 + topology/sof-apl-da7219.m4 | 104 +++++++++++++++++++++++++++++++++++++++++++++ topology/sof-glk-codec.m4 | 30 ++++++------- 3 files changed, 120 insertions(+), 15 deletions(-) create mode 100644 topology/sof-apl-da7219.m4 -- 2.14.1

3 10

Re: [Sound-open-firmware] .m4 File Request Help Needed
by Ranjani Sridharan 04 Jul '18

04 Jul '18

On Wed, 2018-07-04 at 06:22 +0000, Nahulanthran, Sanjeev wrote: > Hi there, > > Managed to build the topology file that I needed. Thanks for your > help! Enabled some extra kernel logs to confirm that the tplg file > being used matches the one I have created. > > However, still obtaining this issue (dmesg logs attached) - > sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered > sof-audio sof-audio: error: ipc error for 0x80010000 size 0xc > sof-audio sof-audio: error: failed to set DAI config for SSP2 > sof-audio sof-audio: error: DSP trace buffer overflow 16 bytes. Total > messages 699 Hi Sanjeev, Copying the list too. This looks like you might be missing some kernel patches. Could you please share the tree you're using for the kernel, firmware and topology? Thanks, Ranjani > > Right now using tplg base file "reef-apl-nocodec.tplg" (modified to > suit my needs, m4 also attached to email) from 1.1-stable branch of > SOFT and using firmware file "reef-apl.ri" from master branch of SOF. > > Can load the soundcards - shown using "aplay -l", however when > playback is initiated, ipc error is shown as stated above. What could > be the reason for this error? Tracing error code leads to function > tx_wait_done in driver code ipc.c (data received from DSP is invalid > I think). How can I resolve this? > > Hope you can extend some help regarding this. Thank you very much for > your time :) > > Thanks and Regards, > Sanjeev > > -----Original Message----- > From: Ranjani Sridharan [mailto:ranjani.sridharan@linux.intel.com] > Sent: Wednesday, July 4, 2018 5:31 AM > To: Nahulanthran, Sanjeev <sanjeev.nahulanthran(a)intel.com> > Subject: Re: [Sound-open-firmware] .m4 File Request Help Needed > > On Tue, 2018-07-03 at 08:01 +0000, Nahulanthran, Sanjeev wrote: > > Hi there, > > > > Somehow I am unable to bring up my soundcard except with this tplg > > file: > > test-ssp*-DSP_A-volume-s32le-s24le-48k-nocodec.tplg > > > > Would you happen to have the .m4 reference for this topology file > > so > > that I can modify it for my own needs and build? I understand how > > to > > configure the DAI section now :) thanks btw > > > > Somehow trying to configure the reference .m4 given to me was not > > successful. I need the .m4 to build this kind of tplg file (test- > > ssp*-DSP_A-volume-s32le-s24le-48k-nocodec.tplg), from there I can > > make > > my modifications as necessary. > > The easiest way is to just add a line to tplg-build.sh script like > this: > > simple_test nocodec volume "NoCodec-2" s24le SSP 2 s16le 25 16 > 2400000 > 24000000 I2S 0 SIMPLE_TESTS[@] > > The above line would create the tplg file you are looking for. Please > remember to modify the SSP port, container bits, valid bits, bclk and > mclk to suit your needs. > > Hope this helps. > > > > Thanks and Regards, > > Sanjeev > > > > -----Original Message----- > > From: Ranjani Sridharan [mailto:ranjani.sridharan@linux.intel.com] > > Sent: Sunday, July 1, 2018 4:55 AM > > To: Nahulanthran, Sanjeev <sanjeev.nahulanthran(a)intel.com>; sound- > > ope > > n-firmware(a)alsa-project.org > > Subject: Re: [Sound-open-firmware] .m4 File Request Help Needed > > > > On Thu, 2018-06-28 at 05:58 +0000, Nahulanthran, Sanjeev wrote: > > > Hi there, > > > > > > Writing this e-mail to request for SOF support in providing a > > > .m4 > > > file with 48kHz, TDM8, and MCLK enabled - used for Cirrus Logic > > > CS42435. > > > This is required as we need it as a reference to make our own > > > modifications to enable the same configuration for another device > > > (amplifier) that we have. > > > > Hi Sanjeev, > > > > Please take a look at the example m4 files provided in the > > topology/test folder in the SOF tools repo: > > https://github.com/thesofproject/soft > > > > For example to test playback, you can use test-playback.m4 and > > modify > > the DAI config to suit your needs. DAI_CONFIG is defined in the > > dai.m4 file and an example config is: > > > > DAI_CONFIG(TEST_DAI_TYPE, TEST_DAI_PORT, 0, TEST_DAI_LINK_NAME, > > SSP_CONFIG(TEST_SSP_MODE, > > SSP_CLOCK(mclk, TEST_SSP_MCLK, codec_slave), > > SSP_CLOCK(bclk, TEST_SSP_BCLK, codec_slave), > > SSP_CLOCK(fsync, 48000, codec_slave), > > SSP_TDM(2, TEST_SSP_PHY_BITS, 3, 3), > > SSP_CONFIG_DATA(TEST_DAI_TYPE, TEST_DAI_PORT, > > TEST_SSP_DATA_BITS))) > > > > As you can see, all the config parameters are arguments to the > > macro > > and quite self-explanatory. > > > > If you have more questions, please feel free to contact us. > > > > Thanks, > > Ranjani > > > > > > > > Thanks and Regards, > > > Sanjeev > > > Software Engineer > > > > > > > > > _______________________________________________ > > > Sound-open-firmware mailing list > > > Sound-open-firmware(a)alsa-project.org > > > http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmw > > > ar > > > e

3 2