You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/12/22 08:36:27 UTC
[GitHub] [incubator-nuttx-apps] Dan-guanghua opened a new pull request #538: system: nxlooper: add nxlooper for loopback test
Dan-guanghua opened a new pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538
which record and play raw data using audio subsystem
to verify audio record and playback function
Signed-off-by: danguanghua <da...@xiaomi.com>
Change-Id: I2c768b8e8234a31f9622cb9955f785329cf402a5
Signed-off-by: danguanghua <da...@xiaomi.com>
## Summary
## Impact
## Testing
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] patacongo commented on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
patacongo commented on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749528043
Should this go under apps/testing instead of apps/system?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 commented on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749613212
> > > Should this go under apps/testing instead of apps/system?
> >
> >
> > Other two audio tools put to apps/system:
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
> > The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
> > @patacongo do you think so?
>
> I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
>
The design of nxlooper is very closed to nxplayer, e.g. there is a simple interpreter to accept user command after launching nxlooper. And nxlooper more like a debugging tool to diagnose the audio driver functionality and then require the developer verify the result by ear manually.
> How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
>
Yes, it's better to move the application which design for testing(which mean run and report automatically) to apps/testing.
> There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
>
> Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
Yes, this is what I am thinking: let's program under apps/testing report pass/fail with zero/nozero exit code, then we can develop a test driver nsh script to manage all test automatically.
From this perspective, apps/system is more suitable place for nxlooper, because:
1. It's hard to very the result of nxlooper
2. nxlooper is more useful for driver bringup
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 commented on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-750167699
@patacongo do you think this patch is ready for merge after the dissussion?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] patacongo commented on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
patacongo commented on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749550268
>
>
> > Should this go under apps/testing instead of apps/system?
>
> Other two audio tools put to apps/system:
> https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
> https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
> The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
> @patacongo do you think so?
I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 commented on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749542494
> Should this go under apps/testing instead of apps/system?
Other two audio tools put to apps/system:
https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
@patacongo do you think so?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 edited a comment on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749613212
> > > Should this go under apps/testing instead of apps/system?
> >
> >
> > Other two audio tools put to apps/system:
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
> > The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
> > @patacongo do you think so?
>
> I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
>
The design of nxlooper is very closed to nxplayer, e.g. there is a simple interpreter to accept user command after launching nxlooper. And nxlooper more like a debugging tool to diagnose the audio driver functionality and then require the developer verify the result by ear manually.
> How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
>
Yes, it's better to move the application which design for testing(which mean run and report automatically) to apps/testing.
> There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
>
> Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
Yes, this is what I am thinking: let's program under apps/testing report pass/fail with zero/nozero exit code, then we can develop a test driver nsh script to manage all tests automatically. Actually, @ttnie is working on this.
From this perspective, apps/system is more suitable place for nxlooper, because:
1. It's hard to very the result of nxlooper
2. nxlooper is more useful for driver bringup
Personally I prefer to put programs which can easliy or potentially run/report automatically to apps/testing, so the test driver could find the test case more easier.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 merged pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 merged pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 edited a comment on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749613212
> > > Should this go under apps/testing instead of apps/system?
> >
> >
> > Other two audio tools put to apps/system:
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
> > The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
> > @patacongo do you think so?
>
> I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
>
The design of nxlooper is very closed to nxplayer, e.g. there is a simple interpreter to accept user command after launching nxlooper. And nxlooper more like a debugging tool to diagnose the audio driver functionality and then require the developer verify the result by ear manually.
> How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
>
Yes, it's better to move the application which design for testing(which mean run and report automatically) to apps/testing.
> There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
>
> Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
Yes, this is what I am thinking: let's program under apps/testing report pass/fail with zero/nozero exit code, then we can develop a test driver nsh script to manage all tests automatically. Actually, @ttnie is working on this.
From this perspective, apps/system is more suitable place for nxlooper, because:
1. It's hard to very the result of nxlooper
2. nxlooper is more useful for driver bringup
Personally I prefer to put programs which can easliy or potentially run/report automatically to apps/testing, so the test driver could find the test case more easier. How about your thinking?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] xiaoxiang781216 edited a comment on pull request #538: system: nxlooper: add nxlooper for loopback test
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749613212
> > > Should this go under apps/testing instead of apps/system?
> >
> >
> > Other two audio tools put to apps/system:
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
> > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
> > The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
> > @patacongo do you think so?
>
> I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
>
The design of nxlooper is very closed to nxplayer, e.g. there is a simple interpreter to accept user command after launching nxlooper. And nxlooper more like a debugging tool to diagnose the audio driver functionality and then require the developer verify the result by ear manually.
> How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
>
Yes, it's better to move the application which design for testing(which mean run and report automatically) to apps/testing.
> There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
>
> Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
Yes, this is what I am thinking: let's program under apps/testing report pass/fail with zero/nozero exit code, then we can develop a test driver nsh script to manage all tests automatically. Actually, @ttnie is working on this.
From this perspective, apps/system is more suitable place for nxlooper, because:
1. It's hard to very the result of nxlooper
2. nxlooper is more useful for driver bringup
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org