From: "chihhao.chen" <redacted>
The following scenario describes an echo test for
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051).
We first start a capture stream(USB IN transfer) in 96Khz/24bit/1ch mode.
In clock find source function, we get value 0x2 for clock selector
and 0x1 for clock source.
Kernel-4.14 behavior
Since clock source is valid so clock selector was not set again.
We pass through this function and start a playback stream(USB OUT transfer)
in 48Khz/32bit/2ch mode. This time we get value 0x1 for clock selector
and 0x1 for clock source. Finally clock id with this setting is 0x9.
Kernel-5.10 behavior
Clock selector was always set one more time even it is valid.
When we start a playback stream, we will get 0x2 for clock selector
and 0x1 for clock source. In this case clock id becomes 0xA.
This is an incorrect clock source setting and results in severe noises.
We see wrong data rate in USB IN transfer.
(From 288 bytes/ms becomes 144 bytes/ms) It should keep in 288 bytes/ms.
This earphone works fine on older kernel version load because
this is a newly-added behavior.
Signed-off-by: chihhao.chen <redacted>
---
sound/usb/clock.c | 6 ++++++
1 file changed, 6 insertions(+)
On Sat, 24 Jul 2021 06:23:41 +0200,
[off-list ref] wrote:
From: "chihhao.chen" <redacted>
The following scenario describes an echo test for
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051).
We first start a capture stream(USB IN transfer) in 96Khz/24bit/1ch mode.
In clock find source function, we get value 0x2 for clock selector
and 0x1 for clock source.
Kernel-4.14 behavior
Since clock source is valid so clock selector was not set again.
We pass through this function and start a playback stream(USB OUT transfer)
in 48Khz/32bit/2ch mode. This time we get value 0x1 for clock selector
and 0x1 for clock source. Finally clock id with this setting is 0x9.
Kernel-5.10 behavior
Clock selector was always set one more time even it is valid.
When we start a playback stream, we will get 0x2 for clock selector
and 0x1 for clock source. In this case clock id becomes 0xA.
This is an incorrect clock source setting and results in severe noises.
We see wrong data rate in USB IN transfer.
(From 288 bytes/ms becomes 144 bytes/ms) It should keep in 288 bytes/ms.
This earphone works fine on older kernel version load because
this is a newly-added behavior.
Signed-off-by: chihhao.chen <redacted>
Thanks for the patch.
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that the
behavior really depends on the device...
Maybe we need to introduce some flag to handle this commonly, but for
now, let's take the fix as is.
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai [off-list ref] wrote:
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that the
behavior really depends on the device...
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices that
only have *one* clock source.
In that case the clock selector must be set to the only clock source.
This way we keep the generalization without breaking devices with more
than one clock source.
Just an idea.
Thank you,
Geraldo Nascimento
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices that
only have *one* clock source.
Okay, rereading the original commit log from Cihhao Chen I gather
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051) actually has
two clock selectors and only one clock source.
Correct me if I'm wrong.
This is complicated by the fact I haven't been able to find a lsusb -v
of Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051)
Even so, my proposition still stands: devices with only one clock
source and only one clock selector should be able to handle us
selecting the clock selector to the only clock source.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -7,6 +7,8 @@ unsigned int snd_usb_combine_bytes(unsigvoid*snd_usb_find_desc(void*descstart,intdesclen,void*after,u8dtype);void*snd_usb_find_csint_desc(void*descstart,intdesclen,void
*after, u8 dsubtype);
+int snd_usb_count_csint_desc(void *descstart, int desclen, void
*after, u8 dsubtype);
+
int snd_usb_ctl_msg(struct usb_device *dev, unsigned int pipe,
__u8 request, __u8 requesttype, __u16 value, __u16 index,
void *data, __u16 size);
On Sat, Jul 24, 2021 at 3:20 PM Geraldo Nascimento
[off-list ref] wrote:
quoted
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices that
only have *one* clock source.
Okay, rereading the original commit log from Cihhao Chen I gather
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051) actually has
two clock selectors and only one clock source.
Correct me if I'm wrong.
This is complicated by the fact I haven't been able to find a lsusb -v
of Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051)
Even so, my proposition still stands: devices with only one clock
source and only one clock selector should be able to handle us
selecting the clock selector to the only clock source.
On Sat, 24 Jul 2021 17:04:13 +0200,
Geraldo Nascimento wrote:
On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai [off-list ref] wrote:
quoted
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that the
behavior really depends on the device...
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices that
only have *one* clock source.
In that case the clock selector must be set to the only clock source.
This way we keep the generalization without breaking devices with more
than one clock source.
Just an idea.
I don't think it's easy to generalize. All those bugs are more or
less BIOS bugs, and a logic doesn't apply always, just because it's a
bug :) For example, setting the clock selector itself should be a
valid operation from the specification POV, while this leads to
breakage on some devices. So, even if we add a more generic
workaround, we need to see which side effect is more commonly seen at
first.
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai [off-list ref] wrote:
On Sat, 24 Jul 2021 17:04:13 +0200,
Geraldo Nascimento wrote:
quoted
On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai [off-list ref] wrote:
quoted
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that the
behavior really depends on the device...
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices that
only have *one* clock source.
In that case the clock selector must be set to the only clock source.
This way we keep the generalization without breaking devices with more
than one clock source.
Just an idea.
I don't think it's easy to generalize. All those bugs are more or
less BIOS bugs, and a logic doesn't apply always, just because it's a
bug :) For example, setting the clock selector itself should be a
valid operation from the specification POV, while this leads to
breakage on some devices. So, even if we add a more generic
workaround, we need to see which side effect is more commonly seen at
first.
Takashi
Hello,
Like I said in one of the other emails in this thread, it's hard to
pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
question.
But from the description Chihhao Chen gave in the original message,
I'm *guessing* the Clock Source for the Samsung USB Headset (AKG) runs
at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
This is all a wild guess, without the lsusb -v it's impossible to be
sure, but if I'm right then the valid setting for the Microphone's
Clock Selector is the Clock Multiplier, not the Clock Source, which,
remember, runs at half the clock, hence why Chihhao Chen sees half the
data rate for USB IN.
Unfortunately our kernel code presently *does* always set the Clock
Selector to the Clock Source, which is a bad assumption to make in my
humble opinion.
The only valid case for setting the Clock Selector to the Clock Source
is when there's precisely one Clock Selector, precisely one Clock
Source and no Clock Multipliers.
In that special case we may be able to touch the setting of the only
Clock Selector to match the only Clock Source.
And, frankly, the only reason we're forced to do that explicitly is
because some Behringer gear (Archwave AG DACs) gets confused and seems
to somehow keep the old rate on the Clock Selector upon sample rate
change.
Thank you,
Geraldo Nascimento
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai [off-list ref] wrote:
quoted
On Sat, 24 Jul 2021 17:04:13 +0200,
Geraldo Nascimento wrote:
quoted
On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai [off-list ref]
wrote:
quoted
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that
the
behavior really depends on the device...
Dr. Iwai, perhaps we could restrict the generalized fix for the
Behringer UFX1604 / UFX1204 with some simple logic to devices
that
only have *one* clock source.
In that case the clock selector must be set to the only clock
source.
This way we keep the generalization without breaking devices with
more
than one clock source.
Just an idea.
I don't think it's easy to generalize. All those bugs are more or
less BIOS bugs, and a logic doesn't apply always, just because it's
a
bug :) For example, setting the clock selector itself should be a
valid operation from the specification POV, while this leads to
breakage on some devices. So, even if we add a more generic
workaround, we need to see which side effect is more commonly seen
at
first.
Takashi
Hello,
Like I said in one of the other emails in this thread, it's hard to
pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
question.
But from the description Chihhao Chen gave in the original message,
I'm *guessing* the Clock Source for the Samsung USB Headset (AKG)
runs
at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
This is all a wild guess, without the lsusb -v it's impossible to be
sure, but if I'm right then the valid setting for the Microphone's
Clock Selector is the Clock Multiplier, not the Clock Source, which,
remember, runs at half the clock, hence why Chihhao Chen sees half
the
data rate for USB IN.
Unfortunately our kernel code presently *does* always set the Clock
Selector to the Clock Source, which is a bad assumption to make in my
humble opinion.
The only valid case for setting the Clock Selector to the Clock
Source
is when there's precisely one Clock Selector, precisely one Clock
Source and no Clock Multipliers.
In that special case we may be able to touch the setting of the only
Clock Selector to match the only Clock Source.
And, frankly, the only reason we're forced to do that explicitly is
because some Behringer gear (Archwave AG DACs) gets confused and
seems
to somehow keep the old rate on the Clock Selector upon sample rate
change.
Thank you,
Geraldo Nascimento
Thank you, Chihhao.
So I was wrong about Samsung USBC Headset (AKG) with VID/PID
(0x04e8/0xa051) having a Clock Multiplier.
There are two Clock Sources, both linked to the USB SOF with fixed sample rate.
Plus two Clock Selectors which are host-programmable and can be set to
either of the two Clock Sources.
I'm still at a loss to explain what is going wrong here.
Would a printk() reveal the first explicit
uac_clock_selector_set_val() on the Clock Selector associated with
USB_IN sets Clock Source ID to pin 1 with Clock Source ID 0x9?
Or is it the other way around, i.e. it sets the Clock Source ID to pin
2 with Clock ID 0xA for the capture stream Clock Selector?
Chihhao Chen, could you please try the following patch for debugging
purposes and share what is printed in dmesg?
Please try one time with your fix applied and one time without, i.e.
with an otherwise unmodified vanilla kernel.
Thank you,
Geraldo Nascimento
@@ -300,6 +300,7 @@ static int __uac_clock_find_source(struc/* the entity ID we are looking for is a selector.*findoutwhatitcurrentlyselects*/ret=uac_clock_selector_get_val(chip,clock_id);+printk(KERN_ERR"FOR EP %x: Clock Selector %x has pin %d for
Clock Source ID %x selected\n", (unsigned int)fmt->endpoint, clock_id,
ret, sources[ret - 1]);
if (ret < 0) {
if (!chip->autoclock)
return ret;
@@ -324,6 +325,7 @@ static int __uac_clock_find_source(struc sources[ret - 1], visited, validate); if (ret > 0) {+ printk(KERN_ERR "FOR EP %x: Found Source! Clock Selector
%x has pin %d for Clock Source ID %x about to be reselected\n",
(unsigned int)fmt->endpoint, entity_id, cur, sources[cur - 1]);
err = uac_clock_selector_set_val(chip, entity_id, cur);
if (err < 0)
return err;
@@ -344,6 +346,7 @@ static int __uac_clock_find_source(struc if (ret < 0) continue;+ printk(KERN_ERR "FOR EP %x: Found source by trial and
error! Clock Selector %x has pin %d for Clock Source ID %x about to be
selected\n", (unsigned int)fmt->endpoint, entity_id, i, sources[i -
1]);
err = uac_clock_selector_set_val(chip, entity_id, i);
if (err < 0)
continue;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: chihhao chen <redacted>
Hello
<6>[ 150.347456][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.347517][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.384289][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.390920][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.438156][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.438226][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.473547][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.480165][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.513375][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.513439][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.546161][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.552678][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.584347][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.584418][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.617760][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.624253][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.657906][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.657982][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.689571][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.696109][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
Chihhao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Jul 27, 2021 at 10:28 AM [off-list ref] wrote:
From: chihhao chen <redacted>
Hello
<6>[ 150.347456][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.347517][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.384289][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.390920][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.438156][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.438226][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.473547][ T2768] __uac_clock_find_source: FOR EP 81: Clock Selector c has pin 2 for Clock Source ID a selected
<6>[ 150.480165][ T2768] __uac_clock_find_source: FOR EP 81: Found Source! Clock Selector c has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.513375][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.513439][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.546161][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.552678][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.584347][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.584418][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.617760][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.624253][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.657906][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.657982][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
<6>[ 150.689571][ T2768] __uac_clock_find_source: FOR EP 1: Clock Selector b has pin 2 for Clock Source ID a selected
<6>[ 150.696109][ T2768] __uac_clock_find_source: FOR EP 1: Found Source! Clock Selector b has pin 2 for Clock Source ID a about to be reselected
Chihhao
Thank you. Chihhao Chen!
I see both EPs have their Clock Selectors (ID 0xC for EP 81 and ID 0xB
for EP 1) selected to pin 2, i.e. Clock Source ID 0xA.
I'm assuming this log is for the vanilla kernel without Chihhao's fix.
Please correct me if I'm wrong, Chihhao.
From the original commit message for the fix, we know the correct
setting for Clock Selector 0xB should be pin 1, with Clock Source ID
0x9.
Takashi Iwai already shared his perspective that this is a firmware
bug on the device.
I have a hunch that the firmware bug is setting both Clock Selectors
at the same time regardless of which one we want to select
specifically.
Chihhao, please try the below patch and perform another echo test.
Let us know if the echo test works or if it still fails and please
remember to share with us the relevant dmesg logs.
Thank you,
Geraldo Nascimento
Chihhao, please try the below patch and perform another echo test.
Let us know if the echo test works or if it still fails and please
remember to share with us the relevant dmesg logs.
Chihhao Chen,
when I said echo test I meant just test the device and observe if
there are noises related to incorrect clock setting.
I then realized a bit too late that probably in your programming
culture "echo test" refers to the whole technique you used to hook the
kernel and debug the issue to produce the fix.
If you call that technique "echo test" I'm sorry, I didn't know it was
called that way.
I just meant to briefly test to hear if there is noise even when the
clock parameters are correctly hardcoded.
My intent with that patch is to try to prove there's a firmware bug in
action just like Takashi Iwai suggested.
My apologies,
Geraldo Nascimento
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: chihhao chen <redacted>
Hi Geraldo Nascimento,
For echo test, it means we use this earphone to receive and play sounds at the same time.
We found in this case serious noise problem happens.
Log as follows with your patch
<6>[ 175.960387][T401365] __uac_clock_find_source: Clock Selector 0xc has pin 2 selected
<6>[ 175.966980][T401365] __uac_clock_find_source: Clock Selector 0xb has pin 2 selected
<6>[ 176.026251][T400354] __uac_clock_find_source: Clock Selector 0xc has pin 1 selected
<6>[ 176.032406][T400354] __uac_clock_find_source: Clock Selector 0xb has pin 1 selected
There is no noise and I think this should be a firmware bug.
Thanks
Chihhao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Aug 5, 2021 at 7:54 AM [off-list ref] wrote:
From: chihhao chen <redacted>
Hi Geraldo Nascimento,
Hi Chihhao Chen!
For echo test, it means we use this earphone to receive and play sounds at the same time.
We found in this case serious noise problem happens.
That's what I understood initially, and only a little later I became
afraid echo test was the name of the debugging technique you used :)
Thanks for the clarification.
Log as follows with your patch
<6>[ 175.960387][T401365] __uac_clock_find_source: Clock Selector 0xc has pin 2 selected
<6>[ 175.966980][T401365] __uac_clock_find_source: Clock Selector 0xb has pin 2 selected
<6>[ 176.026251][T400354] __uac_clock_find_source: Clock Selector 0xc has pin 1 selected
<6>[ 176.032406][T400354] __uac_clock_find_source: Clock Selector 0xb has pin 1 selected
There is no noise and I think this should be a firmware bug.
From the log I'm afraid my worst assumptions were right.
Regardless of which Clock Selector we want to set, the firmware will
always set them both.
We should contact Samsung now that we have at least a sketch of a bug report...
Thanks,
Geraldo Nascimento